[swift-evolution] Proposal: Always flatten the single element tuple

[Vladimir.S]

On 08.06.2017 9:43, Jonathan Hull wrote:
> Also, I want to repeat what I said on the other thread.  We should revert to Swift 3 
> behavior for this, and then take the time to design the behavior we really want 
> (either for 4.1 or 5).  Anything else will cause us to break people’s code twice…

Yes, *just* ignore/revert a number of connected, actively discussed and accepted, 
implemented(partially for some) proposals, freeze the current broken state of 
function types for very long period without any ability in near feature to fix it.

Instead of improvement of the syntax of the problematic parts of code even after 
release (if not possible to suggest a suitable solution before the release). I don't 
think that *improvements* in syntax can break people's code.

Huh..

> 
> Thanks,
> Jon
> 
>> On Jun 7, 2017, at 11:50 AM, Gwendal Roué via swift-evolution 
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>
>>> Le 7 juin 2017 à 20:33, Gwendal Roué <gwendal.roue at gmail.com 
>>> <mailto:gwendal.roue at gmail.com>> a écrit :
>>>
>>> For example, take those three functions:
>>>
>>> func f(_ closure:(Int, Int) -> ())
>>> func g(_ closure:((Int, Int)) -> ())
>>> func h(_ closure:((a: Int, b: Int)) -> ())
>>>
>>> If one can always write (as in Swift 3):
>>>
>>> f { (a, b) in ... }
>>> g { (a, b) in ... }
>>> c { (a, b) in ... }
>>>
>>> Then one can easily deal with a badly fit closure signature.
>>>
>>> This is most examplified by dictionaries. They always expose (key: Key, value: 
>>> Value) tuples (their Element type). Problem is that 'key' and 'value' are 
>>> identifiers that only matter for dictionaries, not for dictionary users. It's very 
>>> important for dictionary users to forget about tuples, and the `key` and `value` 
>>> words:
>>>
>>> // No pollution
>>> dictionary.map { (name, score) in ... }
>>
>> It looks like some people in this mailing list are horrified by this "request" (not 
>> a feature request, but a request that Swift 3 behavior is restored, actually).
>>
>> What could be the reasons for such a bad reaction?
>>
>> 1: measurable runtime overhead (slower programs in some cases, without any obvious 
>> way for the developper to notice where is the extra cost)
>> 2: measurable compiler overhead (slower compilation)
>> 3: implementation complexity (slower swift progress, technical debt, etc.)
>> 4: other?
>>
>> I understand 1. We are all fascinated by C++ and Rust "zero-overhead". If this is 
>> the main concern of the community, then we may focus the discussion of that very 
>> precise topic.
>>
>> I can live with 2 (just a personal subjective preference)
>>
>> About 3: I can not tell because I lack the necessary skills.
>>
>> 4: enlighten us!
>>
>> Gwendal
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>