> On May 31, 2017, at 3:42 PM, Tony Parker <[email protected]> wrote:
>> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> On Mon, May 29, 2017 at 10:47 PM, Robert Bennett <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> I think the goal of SE 0110 and to a lesser extent 0066 was to disallow
>>> this level of intelligence in the compiler.
>>>
>>> Interesting.
>>>
>>> I happen to think that the goal of SE–110
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md>
>>> was to make Swift's type system “properly distinguish between functions
>>> that take one tuple argument, and functions that take multiple arguments.”
>>> Nowhere does that proposal discuss tuple destructuring, and nowhere does it
>>> discuss optional parentheses around closure parameter lists.
>>>
>>> I might go so far as to say that any commits which *do* affect those
>>> things, cannot possibly be correct implementations of the accepted proposal
>>> SE–110, because SE–110 did not describe any changes there.
>>>
>>> With SE–66
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md>
>>> the case is even more clearcut: that proposal explicitly addresses the
>>> question, “Should we require parentheses in closure expression parameter
>>> lists?“ and answers it in the negative. The core team’s notes
>>> <https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000138.html>
>>> on accepting also specify, “The core team did not feel that this proposal
>>> needed to include required parentheses within closures, which have their
>>> own fairly specific grammar.”
>>>
>>>
>>> While technically feasible, it's not desirable to overload parentheses in
>>> this manner.
>>>
>>> I strongly disagree. Language features are desirable exactly to the extent
>>> that they make life better for developers.
>>>
>>> Moreover, parentheses are *already* optional in closure parameter lists.
>>> Making them mandatory would be source-breaking for no benefit to
>>> programmers. Plus having to write double-parentheses in “dict.map{ ((key,
>>> value)) in … }” would be needlessly annoying.
>>
>> This is basically my perspective. There are language features where we've
>> made an intentional decision to require the user to write things in a
>> specific way. Closure parameter lists are not one of them; we've already
>> committed to using a very permissive and flexible grammar. Perhaps that was
>> a mistake, but it's a mistake we've made and cannot reasonably undo,
>> notwithstanding the proposals that are basically "we should ban
>> such-and-such style that, coincidentally, I happen not to use." In the long
>> term, I feel confident that we can deliver an implementation that resolves
>> the multiple-parameter vs. tuple-decomposition ambiguity without making any
>> significant compromises, but I'm not sure whether we can reasonably achieve
>> that in 4.0.
>>
>> John.
>
> As far as I can tell, right now is the earliest possible opportunity for us
> to get real feedback on the impact of this proposal.
>
> Therefore, it seems unfortunate that the apparent response is that it is
> already too late to fix the problem. Or, perhaps I am misunderstanding?
I am not trying to say that it is too late to fix the problem. Some solutions
might be off the table, but we need to investigate what we can do.
John.
>
> - Tony
>
>>
>>>
>>> In my view there have been far too many calls for making Swift “consistent”
>>> in ways that actually make it less enjoyable to use. That is the opposite
>>> of “Swifty”, and we should instead prioritize convenience for users above
>>> rigid consistency of implementation.
>>>
>>> In the case at hand, with Dictionary.map, the vast majority of the time the
>>> user doesn’t actually care whether the closure takes two arguments or a
>>> single 2-tuple argument. They just know that it takes a key and a value,
>>> and they want to be able to write “dict.map{ (key, value) in … }”.
>>>
>>> Sure, the closure *does* take a 2-tuple, and it does not take two
>>> arguments, but the programmer *using* it shouldn’t have to bother about
>>> that distinction most of the time. They just want to assign the key to one
>>> identifier and the value to another. If they try to write “key, value”
>>> without any parentheses the compiler will complain and they’ll add the
>>> parens. But if the compiler demands a *second* set of parentheses, that
>>> will just seem ridiculous.
>>>
>>> Nevin
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
