static arrays becoming value types

[Denis Koroskin]

On Wed, 21 Oct 2009 22:41:50 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> 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

Well, he could just change the symbol used to denote comma operator to  
some other character (if he uses it so heavily internally), and don't  
expose it to a user.

I don't use tuples a lot myself, but I would love to have multiple return  
types without some clumsy syntax. It's possible even now, but the syntax  
is a bit discouraging:

Tuple!(int,float) foo()
{
     return tuple(42, -1.0f);
}

make_tuple(a, b) = foo();

as opposed to:

(int, float) foo()
{
     return (42, -1.0f);
}

(a, b) = foo();