Worst ideas/features in programming languages?

[Walter Bright]

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. Having a struct 
implicitly convertible to a tuple will also likely cause overloading confusion 
and will break legacy code.

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.

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