Worst ideas/features in programming languages?

Timon Gehr timon.gehr at gmx.ch
Tue Jan 4 03:09:30 UTC 2022

On 03.01.22 10:08, Walter Bright wrote:
> On 1/2/2022 11:40 PM, Timon Gehr wrote:
>> On 12/29/21 7:48 AM, Walter Bright wrote:
>>> On 12/28/2021 9:14 PM, Walter Bright wrote:
>>>> Actually, I agree with the need for tuples, and am very open to a 
>>>> good design for it.
>>> I'd like to see something that unified arrays, structs, argument 
>>> lists (for functions).
>> I would like to do that, but I think it would break code like this:
>> void foo(int a,int b){}
>> void foo(int[2] x){}
>> After unification, those two function definitions would now be the same.
>> Is this what you have in mind?
> Not exactly, since the ABI won't permit it. For example,
>      struct S { byte b; int c; }
>      byte b;
>      int c;
>      void func(byte, int);
> I can't call func with S(b,c); because of the function call ABI. 
> ...

My DIP draft extends "alias this" to allow this (which should work anyway):

alias Seq(T...)=T;
struct S{
     byte b;
     int c;
     alias this=Seq!(b,c);

void func(byte,int);


Then it proposes to make tuples a struct template with such an alias this.

Of course, it would also be possible to make tuples a built-in type, 
which would be my preferred design for a new language.

> Having a struct implicitly convertible to a tuple will also likely cause 
> overloading confusion and will break legacy code.

Yes, I don't want that. The benefit of introducing tuples as a struct 
template is precisely that it is a lot less likely to cause confusion in 
legacy code. It does have some significant drawbacks, e.g. 
`foo(int,int)` and `foo((int,int))` would have a different ABI and the 
second overload can't be called as `foo(1,2);`...

> But we could support conversions. For example, a tuple could be 
> converted to an anonymous struct with the syntax `struct(b,c)`. (A tuple 
> can already be used to package up arguments to a function parameter list.)
> The ABI has no way to return a tuple from a function. But a function 
> returning a tuple can be done by packing it into an anonymous struct and 
> then unpacking it at the call site. This can happen under the hood, the 
> user just sees a tuple.
> ...

Returning expanded values from functions is interesting (and my compiler 
frontend allows it), but I don't think that's really the main issue here.

> So, no, implicit conversions of Array <=> Struct <=> Tuple will likely 
> cause many problems. But explicit conversions should work.

To be very clear, I want this:


An this is generally what people mean when they talk about "tuples".

More information about the Digitalmars-d mailing list