Now that we enforce semicolon or newline separation between statements, we can relax the whitespace requirements on '(' and '[' tokens. A "following" token is now just a token that isn't at the start of a line, and any token can be a "starting" token. This allows for:
a(b)
a (b)
a[b]
a [b]
to parse as applications and subscripts, and:
a
(b)
a
[b]
to parse as an expr followed by a tuple or an expr followed by a container literal.
Swift SVN r4573
Provide distinct syntax 'a as T' for coercions and 'a as! T' for unchecked downcasts, and add type-checker logic specialized to coercions and downcasts for these expressions. Change the AST representation of ExplicitCastExpr to keep the destination type as a TypeLoc rather than a subexpression, and change the names of the nodes to UncheckedDowncast and UncheckedSuperToArchetype to make their unchecked-ness explicit and disambiguate them from future checked casts.
In order to keep the changes staged, this doesn't yet affect the T(x) constructor syntax, which will for the time being still perform any construction, coercion, or cast.
Swift SVN r4498
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
Opening brackets after a keyword have to lex as l_paren_call or l_square_subscript in order for expressions like 'super.constructor()' or 'super[i]' to parse. While we're here, let's move the keyword and punctuator list to a metaprogrammable Tokens.def header too. Update decl and stmt parsers to use 'isAnyLParen' so that, e.g., 'constructor(' and 'constructor (' both work as before.
Swift SVN r3846
The lexer now models tuples, patterns, subscripting, function calls, and
field access robustly. The output tokens are now better named as well:
l_paren and l_paren_call, and l_square and l_square_subscript. It
should be much more clear now which one to use. Also, the use of
l_paren or l_square will not arbitrarily flip flop if the token before
it is a keyword or if the token before it was the trailing ']' of an
attribute list. Similarly, tuples will always cause the lexer to produce
l_paren, regardless if the user typed '((x,y))' or '( (x,y))'.
When we someday add array literals, the right token is now naturally
falling out of the lexer.
Swift SVN r3840
and use this information as cues in the language. Right now,
we do not accept things like "-- *i" because the prefix
operator is not correctly right-bound; instead you have to
write "--(*i)". I'm okay with that; I did add a specialized
diagnostic recognizing operator-binary in a place where we're
expecting a potential operator-prefix.
Swift SVN r2161
Per discussion, this should probably be "no newline since the last
token", but that decision should be made simultaneously for ( and [.
Swift SVN r1461
I chose to just delete the -lex action in swift, since it was only useful for
about 10 minutes during bringup and probably never will be again.
Swift SVN r557
think about will occur when/if we want to support attributes on func expression.
That should look like "func [attributes]{ ... }" but now that requires looking
beyond that attributes to know if this is a funcdecl or funcexpr. Nothing that
more heroic lookahead can't handle.
Swift SVN r486
func is sugar for. Unfortunately, we can't use 'func' without introducing ambiguity
since decls and exprs can exist in the same context, I'm not wed to 'lambda' as the
keyword, thoughts welcome.
Swift SVN r467
where you can optionally declare a receiver type. This is cleaner both conceptually
and in implementation, and eliminates drug references. :)
Swift SVN r444
is no AST building or typechecking support yet. Document the intended
semantics in LangRef. This is clearly subject to change, but is a starting
point.
Swift SVN r393
