On 05.07.2016 8:39, Greg Lutz via swift-evolution wrote:
Vladimir.S via swift-evolution <swift-evolution@...> writes:Proposal: =============== 1. Separate function types with parameter list and a tuple parameter. They should be two separate types. 2. Require this syntax to assign tuple parameter's sub-values to variables in func/closure: `{ ((x, y)) in ..}`, otherwise (i.e. if `{ (x, y) in ..`) treat function/closure as having list of parameters. 3. Disallow implicit conversion between function/closure with a list of parameters and function/closure where single tuple is required. This will stop confusion and make the language consistent how it deal with tuples and list of parameters in func/closure. 4. It seems like we should keep the ability to explicitly convert one to another as some(many?) code can depend on this current behavior and so we need a way to convert old code to new.+1, at least. Please see my bug report SR-1795 ("An overloaded function where one instance takes a tuple and the other takes the members of the tuple will crash in SILGen.") This has been true of every Swift compiler since at least July 2015. It's a clear consequence of the knots the compiler gets itself into when the distinction between tuples and parameter lists is muddy. BTW, it's unfortunate that, even with this proposal in effect, `{ x, y in ..}` means the same thing as `{ (x, y) in ..}`, whereas `{ ((x, y)) in ..}` is different from those two, but the same as `{ (((x, y))) in ..}`.
As was discussed earlier, it seems like most of us agree that we should not require the parenthesis for arguments in closure. But from other side, function with list of parameters has parenthesis - so it is natural that (x, y) in closure should means exactly the same as in function declaration - list of parameters. So, then only ((x, y)) should mean 1 parameter of tuple type.
As for ((((((x, y)))))) I repeatedly suggest to disallow such syntax, but seems like no one care so.. we have what we have.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
