[swift-evolution] Revisiting SE-0110

[Gwendal Roué]

> Le 4 juin 2017 à 19:16, Chris Lattner via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> One way to split the difference here is to eliminate the splatting behavior, but keep the destructuring (irrefutable pattern matching) behavior as well.  In these cases, just require an extra explicit paren for the parameter list.  This would change the diff's to:
> 
> Example 1
> -        return columns.index { (column, _) in column.lowercased() == lowercaseName }
> +       return columns.index { ((column, _)) in column.lowercased() == lowercaseName }
> 
> Example 2 :
> -            .map { (mappedColumn, baseColumn) -> (Int, String) in
> +            .map { ((mappedColumn, baseColumn)) -> (Int, String) in
> 
> Example 3 :
> -                .map { (table, columns) in "\(table)(\(columns.sorted().joined(separator: ", ")))" }		
> +                .map { ((table, columns)) in "\(table)(\(columns.sorted().joined(separator: ", ")))" }		
> 
> Example 4 :
> -                dictionary.first { (column, value) in column.lowercased() == orderedColumn.lowercased() }
> +                dictionary.first { ((column, value)) in column.lowercased() == orderedColumn.lowercased() }
> 
> 
> What do you think?  Seems like it would solve the type checker problem, uglify the code a lot less, and make the fixit/migration happily trivial.
> 
> -Chris

Thanks for your feedback !

Your solution performs much better, but only to some point: the developers will just add parenthesis until the compiler is happy.

Quoting https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md: <https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md:>

> ## Motivation
> 
> Right now, the following is possible:
> 
> let fn1 : (Int, Int) -> Void = { x in	
>     // The type of x is the tuple (Int, Int).
>     // ...
> }
> 
> 
> let fn2 : (Int, Int) -> Void = { x, y in
>     // The type of x is Int, the type of y is Int.
>     // ...
> }
> 
> A variable of function type where there exist n parameters (where n > 1) can be assigned a value (whether it be a named function, a closure literal, or other acceptable value) which either takes in n parameters, or one tuple containing n elements. This seems to be an artifact of the tuple splat behavior removed in SE-0029.
> 
> The current behavior violates the principle of least surprise and weakens type safety, and should be changed.

The motivation section is not at all about any "type checker problem". It's about a postulate that has been proven horribly source-breaking, and counter-productive. The type safety argument is moot. The principle of least surprise has been blown away by SE-0110, putting Swift aside from the majority of other languages.

I'm surprised that everybody tries to workaround SE-0110 consequences, admitting that it's relevant, instead of revisiting SE-0110 at its very root.

Gwendal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170605/ca153801/attachment.html>