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
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
When parsing an expression, if we see the production [[identifier '<']], use the following heuristic to choose whether to parse it as a type list or as an operator expression:
- Speculatively parse the subsequent production as a type parameter list.
- If the parse succeeds, examine the token after the closing '>'. If it is one of the following:
l_paren_following
l_square_following
r_paren
r_square
l_brace
r_brace
comma
semicolon
period
then accept the parse as a type list.
- If the parse fails, or if the type list is not followed by one of those tokens, reject the type list and parse as an operator expression.
This only implements the parsing rule. The type parameters are just dropped on the floor--the AST representation and Sema changes are forthcoming. Encouragingly, no test or library code appears to be broken by this rule.
Swift SVN r4044
