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