Unwrapped Arguments for Functions

[mayoff (Rob Mayoff)]

@jeremyabannister

My vote would be that all arguments are first evaluated, then if one of the unwrapped arguments is nil the function evaluation is skipped.

There is already a construct in the language similar to the one you propose: a throwing expression. We should look at how it interacts with the evaluation rules.

For example, here's an expression using your proposed syntax:

f(a, maybe0()?, b, maybe1()?, c)

and here is the analogous expression with throwing subexpressions:

try? f(a, try mightThrow0(), b, try mightThrow1(), c)

Note that any of the identifiers in either expression could refer to a computed property or in general could be replaced by a function call or an arbitrarily complex subexpression.

Your proposed rule is, I guess, to evaluate f(a, maybe0()?, b, maybe1()?, c) as follows:

1. f
2. a
3. maybe0
4. maybe0(), using the result of step 3
5. b
6. maybe1
7. maybe1(), using the result of step 6
8. c
9. f(...) using the above results, if steps 4 and 7 evaluated to .some

But Swift requires the analogous expression try? f(a, mightThrow0(), b, mightThrow1(), c) to be evaluated as follows:

1. f
2. a
3. mightThrow0
4. mightThrow0(), using the result of step 3, and stopping if this step throws
5. b
6. mightThrow1
7. mightThrow1(), using the result of step 6, and stopping if this step throws
8. c
9. f(...)

I would prefer both expressions to follow the same rules, and we can't change the rules for the throwing expression without breaking source compatibility.