[swift-evolution] Revisiting SE-0110

[Robert Bennett]

Er, I think I misunderstood the proposal and discussion and prior work (e.g. SE-0066 <https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md>) and so my contribution to this discussion was not great. Here are my revised thoughts in light of a reread of the relevant material. Below is an outline of what I think closure signatures should look like. (For all of the below examples, the ability to explicitly include return type in the closure "preamble" is assumed.)

0) If a closure takes no arguments, acceptable "preambles" should be: omitting named variables and the "in" keyword, "() in", or "Void in".

1) If a closure takes one argument, acceptable preambles should be: "(arg) in" or "(_) in".

2) If a closure takes at least two arguments, acceptable preambles should be, e.g., "(x, y) in", with every spot in the tuple replaceable by an underscore.

3) If a closure takes at least one argument, "_ in" means that *all* arguments are ignored, regardless of how many there are. For a single-argument closure, "_ in" is shorthand for "(_) in". For multiple-argument closures, it is shorthand for "(_, _, …, _) in". "_ in" is not allowed for nullary closures.

4) Tuple unpacking can be achieved by replacing the variables inside the outer parentheses with tuples. For a Dictionary, whose Element is of type (key: Key, value: Value), this means writing "((key, value)) in", i.e., replacing the "arg" in "(arg) in" with "(key, value)". For a Dictionary<String, (Int, Double)>, you could do "((s, (i, d))) in". If and only if the tuple in question had named positions, they would also be allowed in the closure preamble. So for a Dictionary<String, (length: Int, score: Double)> you could write "((key: s, (length: i, score: d))) in". The rules for tuple position labels would be the same as for regular tuples (whatever those may be; I can never keep track of exactly what is (dis)allowed).

5) The only point I foresee sparking much debate: there should be no permissible shorthands/syntactic sugar except for those outlined above. In particular, parentheses should be required for all closures taking a nonzero number of arguments.

Rationale: Allowing the shorthand "arg in" suggests that when arg is a tuple, "(x, y) in" should accomplish the unpacking, which is incorrect. Allowing the shorthand "x, y in" suggests that for single-argument closures, "arg in" should be allowed, which (according to this) would be incorrect. I don't like the idea of special-casing the syntactic sugar and allowing users to drop the outer parentheses as long as the closure does not take one argument that is a tuple (I think that's the only case the compiler would be unable to resolve). Also, I would imagine the migration path to enforce parentheses around arguments is trivial to implement.

Requiring parentheses also finishes the job started by SE-0066. In fact it more or less perfectly mirrors the proposed solution <https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md#proposed-solution> to the problem of function types.. The only difference here is that we're talking about argument lists, not function types, but why pass up an opportunity to unify the two?

—
Robert Bennett


> On May 27, 2017, at 8:23 AM, Gwendal Roué <gwendal.roue at gmail.com> wrote:
> 
>> Le 27 mai 2017 à 14:20, Gwendal Roué <gwendal.roue at gmail.com <mailto:gwendal.roue at gmail.com>> a écrit :
>> 
>>> Le 26 mai 2017 à 21:35, Robert Bennett via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> On the contrary I think the solution can absolutely be to break other code. 
>> 
>> You can break whatever you want.
>> 
>> But whatever the solution you come up with, remember that SE-0110 currently *degrades* the quality of code written by Swift programmers. It can be argued that SE-0110 is a blatant *regression*. Maybe not as bad as the initial introduction of fileprivate, but something which is pretty bad, though.
>> 
>> References:
>> - https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036808.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036808.html>
>> - https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036814.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036814.html>
> One more link, about the loss of single-lign closures induced by SE-0110: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036792.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036792.html>
> 
> Gwendal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170528/8e431c8f/attachment.html>