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

[Timon Gehr]

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.

Consider the following analogy. Let's say we introduce a new built-in 
type `Int` to D. It behaves precisely the same as `int`, but values of 
type `int` and type `Int` are incompatible. Do you think that's a good 
idea? Do you think that instead just not doing so raises any of the 
concerns around implicit casting? Do you think anyone would argue e.g. 
Rust has too liberal implicit casting because they do not have this kind 
of equivalent yet incompatible built-in types?