The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
and cleanup.
I changes cases that had a non-trivial "then" body but a trivial else. Most of the cases in
the stdlib have a trivial "then" clause, so I didn't change them.
Swift SVN r27567
We define two new library functions _knownForceBridgeFromObjectiveC/_knownConditionallyBridgeFromObjectiveC, similar to _forceBridgeFromObjectiveC/_conditionallyBridgeFromObjectiveC. The main difference is that they require their arguments to conform to _BridgedToObjectiveC and _BridgedToObjectiveC. _ObjectiveCType accordingly. With this change, it is now possible to invoke the _BridgedToObjectiveC._forceBridgeFromObjectiveC witness directly, without going via the inefficient swift_bridgeNonVerbatimFromObjectiveC.
So now, for a cast O -> S, if it can be statically proven that an ObjC type O is bridgeable to a Swift type S implementing the _BridgedToObjectiveC protocol (i.e. O is the class (or its subclass) defined by the S._ObjectiveCType alias), we can generate a code to invoke the newly defined library function _knownForceBridgeFromObjectiveC/_knownConditionallyBridgeFromObjectiveC instead of _forceBridgeFromObjectiveC/_conditionallyBridgeFromObjectiveC.
After inlining, this will end-up invoking S._forceBridgeFromObjectiveC directly instead of invoking a more general, but less effective swift_bridgeNonVerbatimFromObjectiveC, which always performs conformance checks at runtime, even if conformances are known statically. As a result, no conformance checks are performed at run-time if conformances are known statically.
The client code making use of these new APIs and the tests are coming in the subsequent commits.
The naming of the two new helper library functions was discussed with Dmitri.
This is part of the bridging casts optimization effort. And it is specifically useful for e.g. rdar://19081345.
Swift SVN r27100
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
