static arrays becoming value types

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Oct 21 11:41:50 PDT 2009


language_fan wrote:
> Wed, 21 Oct 2009 12:35:35 -0500, Andrei Alexandrescu thusly wrote:
> 
>> language_fan wrote:
>>> void main() {
>>>   Tuple!(int,int) a; // typeof(this) *is* the official tuple type
>>>   STuple!(int,int) b;  // this is actually a struct
>>>
>>>   a = Tuple!(1,1);  // ok
>> That doesn't work for me at all (with std.typecons.Tuple). I think there
>> is confusion about a couple of things. One is that Tuple!(int, int) is a
>> type that contains two ints, whereas Tuple!(1, 1) is a type that
>> contains two compile-time integral values. So if you write:
>>
>> a = Tuple!(1, 1);
>>
>> that is as good syntactically as:
>>
>> a = int;
> 
> It might be if we use your definition of tuple. But the mighty compiler 
> dmd 2.035 himself calls my types constructed with my template
> 
>>> template Tuple(T...) { alias T Tuple; }
> 
> a tuple. How do you explain that? If the resulting type is tuple 
> according to dmd, why do you think it is actually not.
> 
> If it works like you say, why does this work then?
> 
>>>  Tuple!(int,int) a;
>>>  a = Tuple!(12,13);
> 
> Here 'a' has a real runtime type (int,int) which is a runtime tuple 
> according to dmd. And I assign a value to the tuple on runtime. I can 
> even test it by printing the values a[0] and a[1] with writefln. So why 
> didn't you just fix this particular tuple type and why did you come up 
> with a library level hack?
> 
> Show me a better way to achieve this with your tuple system.

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];

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

>>>  int d,e;
>>>  Tuple!(d,e) = Tuple!(10,20);
> 
> It's still not clear to me why you don't want to add full syntactic 
> support for built-in tuples. Do you somehow find this kind of code 
> difficult to read or maintain?
> 
> (int,int) a = (1,1);
> int e1 = a[0];
> 
> writefln(a);
> 
> (int,int) retTest() { return (1,1); }
> 
> int d,e;
> 
> (d,e) = (10,20);
> 
> (d,_) = (10,20);
> 
> (int,int) b;
> (d,b) = (1, retTest());
> 
> auto a3b = [ (1,1), (2,2) ];
> 
> auto a7 = [ (1,1) : 5 ];
> 
> auto a8 = [ 5 : (1,1)];
> 
> I want to know what is the rationale behind not accepting this semantics 
> that is so widely used in other languages (and I very well mean the 
> languages that *have* built-in tuple types).

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).


Andrei



More information about the Digitalmars-d mailing list