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 operatorreally.long.lvalue[expression] ||= ""which works the same way and which is very popular. This lowers the barrier of entry for programmers from that language.
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
inoutkeyword indicates copy-in/copy-out argument behavior. In its current implementation the keyword prepends argument names. We propose to move theinoutkeyword 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
inoutparameter into a escapable closure is an error. We added the explicit@noescapeannotation 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.
