static arrays becoming value types

[grauzone]

Denis Koroskin wrote:
> 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();

Or even:

a, b = foo();

or

a, _ = foo();

Works in Python (tm)