[swift-evolution] Proposal: Remove implicit tuple splat behavior from function applications

[Chris Lattner]

> On Jan 27, 2016, at 9:27 AM, Dave via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Fair enough. Can we get an explicit, well-designed version of this before we get rid of the implicit, poorly-designed version?

I’m certainly not opposed to someone exploring this, but I don’t think it should block removing the bad thing.

> I can’t recall off the top my head where, but I know I’ve done something like this:
> struct FunctionApplicator <T, U> {
>     var args: T
>     let function: T -> U
>     init(args: T, function: T -> U) {
>         self.args = args
>         self.function = function
>     }
>     func apply() -> U {
>         return function(args)
>     }
> }
> 
> Without tuple splatting, you’d need a FunctionApplicator1<T,U>, FunctionApplicator2<T,U,V>, FunctionApplicator3<T,U,V,W>, etc. They can’t even have the same name because Swift doesn’t support overloading type names for types with a different number of generic parameters.

Perhaps I’m misunderstanding, but that is certainly not the case.  Even without the feature in question you can definitely pass a tuple around as a single argument, e.g.:

func f(a : Int, _ b : Int) {…}

let x = FunctionApplicator((42, b: 19), f)

This functionality won’t be affected by removal of this feature.

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