[swift-evolution] [Review] SE-0029 Remove implicit tuple splat behavior from function applications

[Brent Royal-Gordon]

> https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md
> 
> 	• What is your evaluation of the proposal?

-1.

As I said in the preliminary discussion, I use this feature reasonably often and I think my code is better for it. I won't repeat the details here, but suffice it to say, I could work around its absence if I had to but my code would be worse for it.

I do agree that the problems described in the proposal are real, but I think the feature's value is underestimated, and I think the proposed solution maximizes migration difficulties.

I don't agree with the proposal's blithe assertion that tuple splat "is purely a sugar feature". Tuple splat allows you to write generic functions that work with a function of any arity; in fact, it allows *most* generic functions to work in this fashion, even built-in ones like `map` which are designed for unary functions. Even something so simple as a function composition operator is impossible to write without it. In short, you *can* work around its absence, but only by distorting your code and obscuring its purpose—and to a far greater extent than this proposal complains about tuple splat doing.

Finally—and perhaps most importantly, because we're setting a precedent here—the proposal seems very concerned with breaking code now rather than later. However, if the feature is removed without replacement, and then a replacement is added in a later version, that means people using this feature will have to change their code twice: once to remove implicit tuple splat, and again to adopt its eventual replacement. And if the fix-it essentially involves creating a closure to wrap the call, it seems unlikely that removing that closure can be fix-it guided, so the second change will have to be done manually.

Thus, for those using the feature, removing it in Swift 3 and re-adding it in a later version is *more* disruptive than replacing it in Swift 4 or some other future release cycle, while for those *not* using the feature, both strategies cause the same amount of disruption (none).

It's one thing to remove features we don't want to keep, like the `++` operator, or disable only-the-test-suite-will-notice corner cases due to implementation limits, like the curried super calls. It's another thing to remove features we think are a good idea, but want to redesign at some unspecified future date.

Like preemptive war, preemptive feature removal is not an action to be taken lightly. If we want to remove it and replace it, fine. If we want to remove it and *not* replace it, let's talk about that. But removing it and maybe replacing it eventually, but probably not in this release cycle, is essentially the most disruptive possible way this could be handled.

> 	• Is the problem being addressed significant enough to warrant a change to Swift?

Yes, but I don't think the change that should be made is to simply delete the feature and defer any decisions on its replacement.

> 	• Does this proposal fit well with the feel and direction of Swift?

In the sense that we seem to be seeking a stronger separation between tuples and parameters, yes. In the sense that Swift attempts to make higher-order functions practical, no.

> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I've used languages with a variety of parameter type arrangements, and I've always found splatting very useful. I found it useful in Swift, too.

> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A full reading of the proposal, participation in the preliminary discussion thread, review of my codebases to look at where I had used it. I have not really looked at the implementation issues, but other than that, I think I have a pretty good understanding of this proposal.

-- 
Brent Royal-Gordon
Architechies