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

[Timon Gehr]

On 10.05.20 22:59, Mark wrote:
> 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)).

No, that would be terrible.

> 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.

Well, I think this is a bad idea and I did not suggest it.