Worst ideas/features in programming languages?

[Timon Gehr]

On 1/9/22 00:03, Walter Bright wrote:
> On 1/3/2022 7:11 PM, Timon Gehr wrote:
>> On 04.01.22 04:09, Timon Gehr wrote:
>>>
>>> To be very clear, I want this:
>>>
>>> [(1,2),(3,4)].map!((a,b)=>a+b).each!writeln;
>>>
>>> An this is generally what people mean when they talk about "tuples".
>>
>>
>> (I understand that there is something in the DMD source code already 
>> named "Tuple", but that's not really a tuple, it's a sequence of 
>> values that will auto expand into any context. Being able to return 
>> that from functions would be nice, but I think it's independent of 
>> what people are talking about when they want tuples.)
> 
> Yes, and reconciling this will be the problem.
I agree. This is what I had in mind:

- "tuple": the new thing, has an address
- "expanded tuple": the existing thing

If you have a tuple `t`, you can get an expanded tuple using `t.expand`, 
to transform an expanded tuple `e` into a tuple, you use `(e,)`. (This 
is a single-element tuple, this syntax is the same as in e.g. Python. 
Due to auto-expanding of `e`, it can have more than one element.)

In practice, I think expanding is useful, but I'd mostly prefer to use 
tuples that don't auto-expand and expand them explicitly with `t.expand` 
if needed. `t.expand` itself is of course an auto-expanding expression.


In `void foo(T...)(T args)`, `args` would probably still be an expanded 
tuple.

The main challenge is this:

```d
void foo(T)(T arg){}
```

right now, this will never match the following call:

```d
foo(1,2)
```

But with tuples, we could just instantiate it with `T=(int,int)` and 
then the call should match. This is the main reason why the tuple DIP 
did not attempt to allow calling a function with a single tuple 
parameter with multiple arguments, but of course ideally it should work...