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

Zach Waldowski zach at waldowski.me
Wed Jan 27 15:08:29 CST 2016

I agree. I'm +1 for the proposal, but it should be possible for a T to
resolve to an arguments-list type tuple. As I don't often think like a
compiler, I don't know if that would be made harder or easier as a
result of this proposal.

Zachary Waldowski zach at waldowski.me

On Wed, Jan 27, 2016, at 12:27 PM, Dave via swift-evolution wrote:
> Fair enough. Can we get an explicit, well-designed version of this
> before we get rid of the implicit, poorly-designed version?
> 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 {
> returnfunction(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.
> - Dave Sweeris
>> On Jan 27, 2016, at 08:48, Matthew Johnson via swift-evolution <swift-
>> evolution at swift.org> wrote:
>>> On Jan 27, 2016, at 4:18 AM, Nisse Bergman via swift-evolution <swift-
>>> evolution at swift.org> wrote:
>>> -1 I use this in both my mocking API and in JSON
>>> deserialising/serializing. I think this is a great thing to have
>> It would be great to have an explicit, well-designed version of this.
>> Nobody is arguing against that.  But there are quite a few problems
>> with its current form.
> _________________________________________________
> swift-evolution mailing list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160127/0d859d5f/attachment.html>

More information about the swift-evolution mailing list