[swift-evolution] Revisiting SE-0110

[Vladimir.S]

On 06.06.2017 15:32, Gwendal Roué wrote:
> 
>> Le 6 juin 2017 à 12:06, Vladimir.S <svabox at gmail.com <mailto:svabox at gmail.com>> a 
>> écrit :
>>
>> On 06.06.2017 7:36, Gwendal Roué wrote:
>>> http://adcdownload.apple.com/WWDC_2017/Xcode_9_beta/Xcode_9_beta_Release_Notes.pdf
>>>> The migrator does not properly distinquish between single-tuple and 
>>>> multiple-argument function types as described in SE–0110, causing additional 
>>>> mismatched type errors with the closure types that are passed to Standard Library 
>>>> functions expecting tuple objects. (32431899)
>>>>
>>>> Workaround: Manually fix the closure types to accept values of tuples instead of 
>>>> separate argument values.
>>>>
>>>>
>>>> When using $0 and $1 in a closure that is passed to a function expecting a 
>>>> closure with a single tuple argument, the compiler may error after migration with:
>>>>
>>>> error: closure tuple parameter '(TYPE, TYPE)' does not support destructuring with 
>>>> implicit parameters
>>>>
>>>> (32489893)
>>>>
>>>> Workaround: Change $0 and $1 references to $0.0 and $0.1 respectively.
>>>>
>>> Where are the firemen?
>>
>> Could you help me to understand which of my question did you reply on with the 
>> above link and quotes? What are you trying to say? Thank you.
> 
> Oh, just that the Xcode 9 beta release notes list not less than four (four!) known 
> issues related to SE-0110.
> 
> On top of the already discussed regressions introduced by SE-0110, we now have a 
> painful migration.
> 
> I wonder why we're still spilling blood, why the fire hasn't been extinguish yet. 
> Hence: where are the firemen?
> 

I'm just trying to understand your opinion.
Let me know, what result do you *expect* for this Swift4 code given what SE-0066 
requires for function types:

func foo(x : (Int, Int))->() {}

print(type(of: foo))  // ??
print(foo is (_: Int, _: Int)->())  // ??


Vladimir.

> Is there anybody responsible here? When will this endless discussion about 
> "revisiting SE-0110" will eventually end with a reasonable decision?
> 
> When will the proposal process will be amended so that developers should be given a 
> voice, along with language layers, on swift evolution? Developers don't have the same 
> skills as language layers. Too many developers lack the poise and confidence to talk 
> about the future impact of a language modification. Too many language layers fail to 
> admit that some language modification do actual harm on written code after they have 
> invested a lot of time thinking about it. That's normal.
> 
> And that's a recipe for things like SE-0110.
> 
> What I've read here so far makes me think SE-0110 belongs to the "false good ideas", 
> as SE-0025 have been before. Along with SE-0025, maybe SE-0166, it has been deemed 
> "stable" much too early. Unfortunately, the swift evolution process only produces 
> stable amendments that are very painful to fix. I wish the core team would think 
> about it some day: aren't the quality of the language and its core libraries at stake?
> 
> Gwendal
>