Commit Graph

459 Commits

Author SHA1 Message Date
Doug Gregor
63ff23147f Implement another new closure syntax.
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
2013-07-10 01:15:15 +00:00
Doug Gregor
c10b1cef65 Allow trailing closures without pipes wherever we don't expect curly braces.
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
2013-05-21 22:30:25 +00:00
Doug Gregor
ca27f8e2ea ... and the compiler accepted it ;)
Swift SVN r5211
2013-05-17 21:00:24 +00:00
Doug Gregor
4d60bb7173 Implement trailing closure syntax.
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
2013-05-17 19:16:18 +00:00
Doug Gregor
fab984aeae Test and improve parser error recovery for closures.
Swift SVN r5203
2013-05-17 16:39:20 +00:00
Doug Gregor
6e64ca66f0 Treat '|' as a delimiter while parsing the signature of a closure.
'|' is part of the character set for operators, but within the
signature of a closure we need to treat the first non-nested '|' as
the closing delimiter for the closure parameter list. For example,

  { |x = 1| 2 + x}

parses with the default value of '1' for x, with the body 2 + x. If
the '|' operator is needed in the default value, it can be wrapped in
parentheses:

  { |x = (1|2)| x }

Note that we have problems with both name binding and type checking
for default values in closures (<rdar://problem/13372694>), so they
aren't actually enabled. However, this allows us to parse them and
recover better in their presence.



Swift SVN r5202
2013-05-17 16:02:44 +00:00
Doug Gregor
ce3fe3ae92 Implement Ruby-inspired closure syntax.
This commit implements closure syntax that places the (optional)
parameter list in pipes within the curly braces of a closure. This
syntax "slides" well from very simple closures with anonymous
arguments, e.g.,

  sort(array, {$1 > $0})

to naming the arguments

  sort(array, {|x, y| x > y})

to adding a return type and/or parameter types

  sort(array, {|x : String, y : String| -> Bool x > y})

and with multiple statements in the body:

  sort(array, {|x, y|
    print("Comparing \(x) and \(y)\n")
    return x > y
  })

When the body contains only a single expression, that expression
participates in type inference with its enclosing expression, which
allows one to type-check, e.g.,

  map(strings, {|x| x.toUpper()})

without context. If one has multiple statements, however, one will
need to provide additional type information either with context

  strings = map(strings, {
    return $0.toUpper()
  })

or via annotations

  map(strings, {|x| -> String 
    return x.toUpper()
  }

because we don't perform inter-statement type inference.

The new closure expressions are only available with the new type
checker, where they completely displace the existing { $0 + $1 }
anonymous closures. 'func' expressions remain unchanged.

The tiny test changes (in SIL output and the constraint-checker test)
are due to the PipeClosureExpr AST storing anonymous closure arguments
($0, $1, etc.) within a pattern in the AST. It's far cleaner to
implement this way.

The testing here is still fairly light. In particular, we need better
testing of parser recovery, name lookup for closures with local types,
more deduction scenarios, and multi-statement closures (which don't
get exercised beyond the unit tests).



Swift SVN r5169
2013-05-14 05:17:10 +00:00
Doug Gregor
6337523879 Compute captures from the leaves up to the root.
Fixes <rdar://problem/13249017>.


Swift SVN r5049
2013-05-06 16:14:38 +00:00
Doug Gregor
7c2f86d948 Prohibit capture of [byref] parameters.
There is a special-case hack to allow capture of 'this', which is
implicitly [byref] for structs. At the moment, most of the cases where
this hack is necessary are [auto_closure] parameters (for assertions
and &&/||).



Swift SVN r5047
2013-05-06 14:54:22 +00:00