> On May 31, 2017, at 3:53 PM, John McCall <[email protected]> wrote:
>
>> On May 31, 2017, at 3:42 PM, Tony Parker <[email protected]
>> <mailto:[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.
Ok, great, I’m glad to hear that.
Thanks,
- Tony
>
>>
>> - 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
