Unwrapped Arguments for Functions

Evolution Pitches
7

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.

6 Likes