Tuples a first class feature, manu's new unary operator and named arguments

[Mark]

On Sunday, 10 May 2020 at 17:56:22 UTC, Timon Gehr wrote:
> On 10.05.20 14:06, Mark wrote:
>> On Sunday, 10 May 2020 at 03:14:08 UTC, Timon Gehr wrote:
>>> On 09.05.20 19:07, Mark wrote:
>>>> but the syntax is extremely terse (*mytuple).
>>>
>>> def foo(x, y):
>>>     return x + y
>>>
>>> print(map(foo, [(1, 2), (3, 4)])) # without unpacking, does 
>>> not work
>>>
>>> # manual unpacking, kind of not "extremely terse":
>>> print(list(map(lambda t: foo(*t), [(1, 2), (3, 4)])))
>> 
>> Hmmm, very good point.
>> 
>> The issue seems similar (at least in spirit) to that of 
>> implicit casting. Implicit casting is, in a sense, syntactic 
>> sugar, saving you from writing "cast(mytype) myval" all over 
>> the place. It's also a highly contentious issue; everyone 
>> seems to be have their opinion of the extent to which implicit 
>> casting is a good thing.
>
> It's not really similar. The problem is that there are two 
> different things that are actually the same but still formally 
> require conversion between each other. It's busywork without a 
> justification.

They're not strictly the same. Consider the following function 
calls:

foo(1, 2, 3)
foo((1, 2, 3))
foo((1, 2), 3)
foo(1, (2, 3))
foo((1), (2), (3))
etc.

Maybe you intend for tuples to automatically "flatten" in the 
context of a function argument list (that is, all of the above 
expressions would be equal to foo(1, 2, 3)). This is a valid 
design decision but notably this is very different from how array 
and struct literals work. If the signature of foo were

void foo(int[2], int[1]);

then foo([1,2],[3]) is accepted, but foo([1],[2, 3]) is rejected. 
This is the kind of "implicit casting" I'm talking about.