In this syntax, the closure signature (when present) is placed within
the braces and the 'in' keyword separates it from the body of the
closure, e.g.,
magic(42, { (x : Int, y : Int) -> Bool in
print("Comparing \(x) to \(y).\n")
return y < x
})
When types are omitted from the parameter list, one can also drop the
parentheses, e.g.,
magic(42, { x, y -> Bool in
print("Comparing \(x) to \(y).\n")
return y < x
})
The parsing is inefficient and recovers poorly (in part because 'in'
is a contextual keyword rather than a real keyword), but it should
handle the full grammar. A number of tests, along with the whitepaper
and related rational documents, still need to be updated. Still, this
is the core of <rdar://problem/14004323>.
Swift SVN r6105
grammar description in LangRef and the parser to expose a new stmt-control-transfer.
- remove obsolete comment in ParseStmt.cpp talking about stmt-brace.
No behavior change.
Swift SVN r5809
Cast operators no longer have precedence below all operators, but they still end sequence expression parsing because of the type production on their right sides.
Swift SVN r5572
This moves trailing closures from expr-postfix up to the level of
expr, and introduces an intermediate level (expr-basic) for places
that need to parse expressions followed by curly braces, such as
if/while/switch/for. Trailing closures are still restricted to occur
after expr-postfix, although the parser itself parses a slightly more
general and then complains if it got more than an expr-postfix.
Swift SVN r5256
Trailing closure syntax allows one to write a closure following any
other postfix expression, which passes the closure to that postfix
expression as an arguments. For example:
sort(fruits) { |lhs, rhs|
print("Comparing \(lhs) to \(rhs)\n")
return lhs > rhs
}
As a temporary limitation to work around the ambiguity with
if foo { ... } { ... }
we require trailing closures to have an explicit parameter list, e.g.,
if foo { || ... } { ... }
Swift SVN r5210
The description of identifiers got long enough that it makes sense to break operators out into their own subsection. Also, I snuck '@' into the operator character set.
Swift SVN r5006
For example, this allows:
var window = new NSWindow.(initWithContentRect:NSRect(100, 100, 800, 630)
styleMask:Int(NSTitledWindowMask|NSClosableWindowMask|NSResizableWindowMask)
backing:NSBackingStoreType(NSBackingStoreBuffered)
defer:false)
Swift SVN r4315
Introduce a second syntax for method calls that better describes
messages with multiple selector pieces, e.g.,
undoManager.(registerUndoWithTarget:this
selector:"setItemName:"
object:nameSetter)
Note that we're also allowing ':' as a separator for normal keyword
arguments. The intent is to drop the use of '=' for normal keyword
arguments, but that will be a separate change affecting a number of
test cases.
Swift SVN r4313
The range operators (".." and someday "...") make constructs like .24...42
ambiguous. Therefore, we will enforce that programmers either place digits
on both sides of the decimal place, or use of exponent based notation.
Swift SVN r3989
If we're going to import C/C++/ObjC code, we ought to "just work" with
their escape patterns when reasonable. (No error-prone octal escapes or
trigraph support). Also, update LangRef to document what the escapes do.
This patch DOES fix a bug with lexing operators in the case of (already
warned about) embedded NUL bytes within a source file.
This patch DOES NOT change what we consider to be valid whitespace in
the language.
Swift SVN r3970
APFloat's parser gives us the parsing for free. Unlike C99 we require at least one digit on both sides of the hexadecimal point in order to allow '0x1.method()' expressions, similar to Dave's proposed change to float lexing. Also, we were requiring a sign after 'e' in the exponent, which is inconsistent with C, C++, and the Java regex we claim to follow, so I made the exponent sign optional.
Swift SVN r3940
In Swift the "in" keyword is really a form of punctuation, and highly
context specific punctuation at that. It never begins a statement, nor
does the grammar require it be statement keyword. The grammar also
doesn't use it outside of for-each loops, and its use within a for-each
loop is highly unambiguous.
Thanks to Chris for the performance related feedback. This improves the
performance of getter/setter parsing as well.
Swift SVN r3880
