This new syntax aims to be closer to the declaration syntax. For
example, to call this method:
func performSelector(_ : SEL) withObject(obj1 : id) { }
one would use
target.performSelector("doThis:") withObject(object)
The additional selector pieces (e.g., withObject(object)) occur on the
same line; otherwise, they are taken as a separate statement. However,
one can use ':' as a continuation character at the beginning of the
next line to continue the message send, e.g.,
target.performSelector("doThis:")
:withObject(object)
For the 3-argument version, one could use, e.g.,
target.performSelector("doThis:") withObject(object1) withObject(object2)
or
target.performSelector("doThis:")
:withObject(object1) withObject(object2)
or
target.performSelector("doThis:")
:withObject(object1)
:withObject(object2)
depending on the width of your screen.
Note that I've tweaked the parsing of case statements slightly to
accommodate this change, by requiring that the ':' that follows a case
statement not start a new line. Thus,
case foo:
is okay, but
case foo
:
is not. This is mostly paranoia, so that
case target.performSelector("sel"):
is "obviously" a simple method invocation in the case, while
case target.performSelector("sel")
:withObject(object):
is "obviously" a two-argument method invocation in the case.
This syntax has some positives, such as similarity with the function
declaration syntax and being a fairly clean extension of the "normal"
Swift method call syntax. It also has some negatives: we have our
first continuation character (':'), the syntax for constructors is
(again) a bit unfortunate
new NSURL(initWithString="http://www.apple.com")
and it's not clear how to invoke a variadic method with this syntax
without, say, burying the additional arguments in the last argument
(which is currently not permitted), e.g.,
NSString.alloc().initWithFormat("blah") locale(locale, arg1, arg2)
Swift SVN r4366
Implement switch statements with simple value comparison to get the drudge work of parsing and generating switches in place. Cases are checked using a '=~' operator to compare the subject of the switch to the value in the case. Unlike a C switch, cases each have their own scope and don't fall through. 'break' and 'continue' apply to an outer loop rather to the switch itself. Multiple case values can be specified in a comma-separated list, as in 'case 1, 2, 3, 4:'. Currently no effort is made to check for duplicate cases or to rank cases by match strength; cases are just checked in source order, and the first one wins (aside from 'default', which is branched to if all cases fail).
Swift SVN r4359
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
This requires a gross but simple contract between pattern parsing and C
for loop parsing where pattern parsing will gracefully back out if and
only if we have a potential C for loop pattern AND assignment is
detected in the pattern (which isn't otherwise allowed outside of the
context of func decls).
If we ever want "for (((;;)))" to work, then this we'll need to
implement the fully general arbitrary token lookahead. But for now, the
common C style "just works".
Swift SVN r3831
We have no intention of ever supporting actual semicolon statements
(separators, statements no), nor do we ever want to because that would
mean the behavior of the program would potentially change if semicolons
were naively removed.
This patch tracks the trailing semicolon now in the decl/expr/stmt,
which will enable someone to write a good "swift indent" tool in the
future.
Swift SVN r3824
Instead of writing in an awkward special case for SemiStmt in ParseStmt, apply the existing semicolon-eating syntax in ParseDecl for types to the toplevel. Suggested by Jordan re: r3336.
Swift SVN r3342
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
implementing rdar://11360347 / 11349750. C-style for loops could be
further enhanced by allowing a comma-separated list of statements in
the increment, but this isn't something I plan to do in the short term.
Swift SVN r1713
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 haven't really carefully considered whether existing type-checking etc. is correct for the main module (I think the name-binding rules need to be a bit different?), but it seems to work well enough for the obvious cases.
This is enough to get the one-liner "println(10)" to print "10" in "swift -i" mode, although the path to swift.swift still needs to be explicitly provided with -I.
Swift SVN r1325
The later could represent semantic errors, but we'd rather represent those with an
ExprError node instead. This simplifies the code and allows the parser to build a more
fully-formed AST that IDE clients will like.
Swift SVN r1141
not have reference semantics. Deciding whether the container
type has reference semantics requires us to perform
some amount of limited name-binding and type-checking first,
which introduces a few complexities.
Also, fix a bug in uncurried call emission.
Methods work now.
Swift SVN r1112
