<div dir="ltr">I'm +1 if there's a standard library function like this:<div><span style="font-family:Menlo;font-size:11px;color:rgb(187,44,162)"><br></span></div><div><span style="font-family:Menlo;font-size:11px;color:rgb(187,44,162)"> func</span><span style="font-family:Menlo;font-size:11px"> call<T,R>(params: </span><span style="font-family:Menlo;font-size:11px;color:rgb(112,61,170)">T</span><span style="font-family:Menlo;font-size:11px">, function: </span><span style="font-family:Menlo;font-size:11px;color:rgb(112,61,170)">T</span><span style="font-family:Menlo;font-size:11px"> -> </span><span style="font-family:Menlo;font-size:11px;color:rgb(112,61,170)">R</span><span style="font-family:Menlo;font-size:11px">) -> </span><span style="color:rgb(112,61,170);font-family:Menlo;font-size:11px">R</span><br></div><div><span style="font-family:Menlo;font-size:11px"><br></span></div>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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 31, 2016 at 5:34 AM, Haravikk via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 30 Jan 2016, at 11:00, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> 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.<br>
> "Look, boy: First you have to endure a fresh haircut, afterwards we can debate about the merits of visiting the ice cream shop" ;-)<br>
><br>
> 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.<br>
> 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?".<br>
><br>
> 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 ;-).<br>
><br>
>> 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.<br>
> 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.<br>
> But I really hope that decisions in general are not only based on the needs of the majority:<br>
> Many C++ developers never write templates, and some even hate them — but imho their removal would cripple the language.<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>