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

[davesweeris at mac.com]

<scratches head> Then I’ve misunderstood what splatting was. Is the difference between splatting and what my example does the arguments’ labels?
func f(a : Int, _ b : Int) {…}
let x = FunctionApplicator((42, b: 19), f) //Would stay legal, because of the "b:"
let y = FunctionApplicator((42, 19), f)    //Would become illegal, because there’s no “b:”

And we would have to use the internal argument labels? If so, how would that work with functions in 3rd-party libraries, where we might not have access to that information?

- Dave Sweeris

> On Jan 27, 2016, at 10:21, Chris Lattner <clattner at apple.com> wrote:
> 
> 
>> On Jan 27, 2016, at 9:27 AM, Dave via swift-evolution <swift-evolution at swift.org <mailto: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/2d8ce3ef/attachment.html>