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

[Andrew Bennett]

I'm +1 if there's a standard library function like this:

    func call<T,R>(params: T, function: T -> R) -> R

I think that should make it clear when you want this behaviour, and allow
it to be done in those circumstances. I like the idea of a method on
functions, but I don't think Swift is ready for that yet.

On Sun, Jan 31, 2016 at 5:34 AM, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On 30 Jan 2016, at 11:00, Tino Heth via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >> 1. Proposals should be incremental.  Removing this (very rarely used)
> feature is a prerequisite to adding its replacement, particularly given
> that the replacement will have different semantics.
> > "Look, boy: First you have to endure a fresh haircut, afterwards we can
> debate about the merits of visiting the ice cream shop" ;-)
> >
> > I guess all critics could be silenced easily with a realistic
> possibility that the feature will be re-added in a later version, so its
> just a natural reaction to highlight the value of tuple splat now and
> convince many people that it is a nice concept.
> > If this fails, I predict that reactions on a proposal to add tuple splat
> will include statements like "didn't Swift have this in an old version, but
> removed it because it was bad?".
> >
> > A process with small steps is easier to handle and more honest (no one
> can be sure what will happen until Swift 4, so it's good to be careful with
> promises), but it is easier to thrill people with a big picture of the
> future (it is even more easy to disappoint them with a failed vision — and
> we already have enough thrill now ;-).
> >
> >> 2. The proposed addition of the new feature will have to be
> self-justified based on the merits of that proposal.  Those merits will
> depend on the exact design.
> > Considering a common reaction on the proposal ("I never used this, get
> rid of it"), it is hard to foresee how many people would like to add an
> exotic feature that they haven't seen in action.
> > But I really hope that decisions in general are not only based on the
> needs of the majority:
> > Many C++ developers never write templates, and some even hate them — but
> imho their removal would cripple the language.
>
> While I don’t personally use the feature (didn’t even know about it until
> this discussion), I kind of like it, but I also don’t really see what the
> big deal is with just keeping it? It seems like it should be relatively
> easy to just replace it when a new version can be designed, so I don’t
> think there’s much need for it to be done “incrementally” when that means
> ripping it out with no alternative on the horizon.
>
> Though it may currently lead to confusing code for beginners, and so
> should be discouraged by convention except where necessary, I don’t think
> leaving it in really hurts anyone either.
>
> Personally my preference for replacing it would be to add a call() or
> callWithArgs() method to all functions/closures, which coincides quite
> nicely with the discussion for explicit closure execution, which would
> require adding the same kind of functionality anyway, so it might provide a
> good opportunity to adding a “tuple splat” replacement as well. So
> basically calls to foo(args) would become foo.call(args) or similar.
>
> So yeah, I think we should consider replacements before removing “tuple
> splat”, as adding a replacement might not be that much harder than removing
> the feature, and if the replacement is similar to other features under
> consideration then it could be a good opportunity to group them together
> and just do it all in one go.
> _______________________________________________
> 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/20160131/00098c47/attachment.html>