static arrays becoming value types

language_fan foo at bar.com.invalid
Wed Oct 21 12:05:12 PDT 2009


Wed, 21 Oct 2009 13:41:50 -0500, Andrei Alexandrescu thusly wrote:

> I don't understand what you are trying to accomplish. As far as I can
> tell you want to do this:
> 
> Tuple!(int, int) a;
> a = tuple(12, 13);
> int x = a.field[0];

Not only that, but also this:

>>>>  int d,e;
>>>>  Tuple!(d,e) = Tuple!(10,20);

> and similar things. I have no idea why you refuse to do it that way.

You somehow refuse to see that D has a tuple type which the compiler 
calls a tuple. Run 'strings /path/to/dmd|wc -l' and you'll see 28 
instances of the word 'tuple'. If there was no built-in support, why does 
the executable contain the word then?

Here..

>> template Z(T...) { alias T Z; }
>> Z!(int,int) a;
>> pragma(msg,a.stringof);

I did not mention the word tuple, but guess what dmd thinks. If it is not 
a tuple, why does dmd output 'tuple(_a_field_0,_a_field_1)'? Apparently 
this does not follow the math book definition of tuple nor is the 
traditional FPL tuple, but a special D flavor of tuple.

Walter decided to build a tuple type, but something happened and he later 
started restricting its use (IIRC it *was* possible to create an array of 
these tuples, but now it is disallowed). What is left is a half-working 
mess mostly useful for compile time meta-programming. It works rather 
nicely there (except that the auto-flattening is sometimes rather 
annoying), but its operation is broken on runtime. You discarded this by 
stating that D does not have a tuple type, you just call it a 'type that 
contains two ints' in my example. DMD calls it a tuple (see .stringof, 
error messages etc.)

I can see that you try to accomplish the same things with your library 
provided version of tuple. But if that is the recommended way of using 
tuples, why there is a bug riddled version in the compiler of the same 
type. It is extremely exhausting to implement a new compiler for D 
because the reference implementation is full of bugs I mentioned in 
previous posts and you cannot really tell how it should work.

> To effect this, there'd first be a need to eliminate the current
> semantics of the comma operator. I probably find it as useless as the
> next guy, and don't take one second to buy into Walter's theory that it
> makes it easy to generate code (that may as well be his least convincing
> argument to date), but really there's two parts to your suggestion: (1)
> eliminate the comma operator, (2) make the comma operator work for
> tuples. I suspect there are some syntactical issues with (2).

I know that very well..



More information about the Digitalmars-d mailing list