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.r...@gmail.com> wrote: > >> Le 27 mai 2017 à 14:20, Gwendal Roué <gwendal.r...@gmail.com >> <mailto:gwendal.r...@gmail.com>> a écrit : >> >>> Le 26 mai 2017 à 21:35, Robert Bennett via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
