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

[Taras Zakharko]

My opinion closely matches Jens’s. I am very fond of the idea that functions are  just syntactically privileges forms of closures, which themselves are maps from tuples to tuples. Its elegant, explicit, clean and it avoids treating functions as compiler magic. I would like this notion to be even more explicit and I would like to see some tuple algebra that allows one to manipulate functions in a flexible, type-safe way. 

I am not opposed to removal of tuple splat behaviour in its current form, but it would be a shame if such removal would signify that Swift is abandoning the path of formal elegance. Swift is already quite idiosyncratic, with magical bits and pieces all over the language, and I believe that one should aim to have a semantically consistent, lean language rather then a collection of loosely coupled devices with orthogonal semantics. 

— Taras


> On 28 Jan 2016, at 11:48, Jens Persson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> > +-0. I saw, in my dreams, many "different parts" of the language, like pattern matching, function argument- & parameter lists, and tuples, all just being one and the same simple yet powerful unifying concept ...
> > :´ /
> 
> I had that dream too, very early on in Swift development, but it isn’t practical for a very large number of reasons…
> 
> -Chris
> 
> 
> I guess you are right. But I'll take the opportunity to whine a bit anyway, perhaps it might be worth something, coming from my idealistic user/layman's perspective:
> 
> I feel as though the unifying-tuple-concept-dream could still come true, if only:-) the whole thing was redesigned from scratch, with a stronger focus on simplicity and consistency (the rules for argument/parameter lists, parameter naming, tuple types, tuple element labels, pattern matching etc).
> 
> IMHO not being able to eg think of, and use, argument/parameter lists as tuples/tuple types dumbs down and complicates the language, trading expressibility for boilerplate and special-casing.
> 
> Yes, it seems like this aspect of the language are not wildly appreciated and used. But that might be a chicken and egg problem, the current inconsistencies might have been introduced/sustained/amplified by not letting the unifying-tuple-concept place enough selection pressure in the evolution of the language. And another reason might of course be slow changing programming habits / adopting new concepts.
> 
> As I said, I know this is very naive and idealistic, but perhaps it can play a small part in some pragmatic decision making.
> /Jens
> 
> 
> 
> _______________________________________________
> 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/20160128/809b743d/attachment.html>