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

[Taras Zakharko]

> Functions “need” to have things like inout, variadics, default arguments, and other features that either don’t make sense at all (e.g. inout), or are marginally useful but had huge complexity to the user model (varargs and default args).

In all honesty, I’d rather prefer inout  to go, and cases that absolutely need it (FFI) transparently replace inout arguments with multiple return values. I don’t see any issue with variadics and default arguments — they are quite useful features for a generic tuple type. But I understand if following this path is not what the Swift team intends to do and I respect that decision. Its formal elegance vs. pragmatism. Pragmatism is not a bad choice :) 

— Taras

> On 28 Jan 2016, at 19:18, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Jan 28, 2016, at 2:48 AM, Jens Persson <jens at bitcycle.com <mailto:jens at bitcycle.com>> 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.
> 
> As I mentioned, I agree with the general principle of eliminating special cases and having a single unifying principle.  Also, the original swift model was that parameter lists *were just tuples*.  We are still slowly digging the compiler out of that hole.
> 
> Functions “need” to have things like inout, variadics, default arguments, and other features that either don’t make sense at all (e.g. inout), or are marginally useful but had huge complexity to the user model (varargs and default args).
> 
> You’re right that a single unifying principle can be good, but there is a huge value in tuples being simple and self consistent with themselves without a ton of weird stuff hanging out on them just because functions need them.
> 
>> Yes, it seems like this aspect of the language are not wildly appreciated and used. 
> 
> Function parameters are widely used :-)
> 
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/1754a950/attachment.html>