[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