[swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

Greg Lutz greg at nearspace.com
Tue Jul 5 00:39:01 CDT 2016


Vladimir.S via swift-evolution <swift-evolution at ...> 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 ..}`.





More information about the swift-evolution mailing list