> Le 4 juin 2017 à 19:16, Chris Lattner via swift-evolution > <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
