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);
func(S());
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:
[(1,2),(3,4)].map!((a,b)=>a+b).each!writeln;
An this is generally what people mean when they talk about "tuples".
More information about the Digitalmars-d
mailing list