Tuesday, February 16, 2016 [Tweets] [Favorites]

Swift Evolution Proposals

SE-0024: Optional Value Setter ??=:

In certain cases the ?? operation doesn't help with lengthly variable names, i.e., really.long.lvalue[expression] = really.long.lvalue[expression] ?? "". In addition to this other languages such as Ruby contain a pipe operator really.long.lvalue[expression] ||= "" which works the same way and which is very popular. This lowers the barrier of entry for programmers from that language.

SE-0030: Property Behaviors:

There are property implementation patterns that come up repeatedly. Rather than hardcode a fixed set of patterns into the compiler, we should provide a general “property behavior” mechanism to allow these patterns to be defined as libraries.

SE-0031: Adjusting inout Declarations for Type Decoration:

The inout keyword indicates copy-in/copy-out argument behavior. In its current implementation the keyword prepends argument names. We propose to move the inout keyword to the right side of the colon to decorate the type instead of the parameter label.

All of these are currently under review. Property behaviors look very useful.

Update (2016-02-17): SE-0035: Limiting inout capture to @noescape contexts:

I propose we make it so that implicitly capturing an inout parameter into a escapable closure is an error. We added the explicit @noescape annotation in Swift 1.2, and have since adopted it throughout the standard library where appropriate, so the compromise has outlived its usefulness and become a source of confusion.

Previously: Seven Swift Snares.

Update (2016-02-23): Erica Sadun:

The Swift team has rejected three Swift proposals.


Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment