[swift-evolution] Revisiting SE-0110

Robert Bennett rltbennett at icloud.com
Sun May 28 01:32:01 CDT 2017

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>

More information about the swift-evolution mailing list