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

[Timon Gehr]

On 09.05.20 19:07, Mark wrote:
> On Saturday, 9 May 2020 at 14:28:37 UTC, Timon Gehr wrote:
>> On 09.05.20 15:19, Mark wrote:
>>> In mathematics you don't have function overloading. I believe this 
>>> could cause ambiguities if tuple parameters are automatically 
>>> "unpacked".
>>
>> You can easily have function overloading and fully sane tuple 
>> semantics at the same time. It is true that in D, some compromises 
>> might have to be made in order to preserve backwards compatibility. I 
>> think my attempt [1] [2] does that quite well, but maybe there is an 
>> even better way.
>>
>>
>>
>> [1] https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md 
>> (Proposal 2)
>> [2] https://github.com/dlang/dmd/compare/master...tgehr:tuple-syntax
> 
> Personally, I like how Python does it - you have to unpack tuples 
> manually

I don't see any reason why the concept "multiple function arguments" 
should be separate from the concept "multiple tuple elements". It's a 
distinction without a difference and I think it is a design mistake.

> 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)])))


std.typecons.tuple allows expansion with using the notation `mytuple[]` 
(but this is kind of an accident), and it suffers from the same issue 
that Python does.

> It also supports 
> "dictionary unpacking", which allows passing named parameters to 
> functions elegantly, again with very little syntactic overhead (**mydict).

Yes, unfortunately so far this concept has been missing from named 
argument DIPs.