Array literals

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:gd7mgi$2f83$1 at digitalmars.com...
> Steven Schveighoffer wrote:
>> "Andrei Alexandrescu" wrote
>>> Steven Schveighoffer wrote:
>>>> "Sergey Gromov" <snake.scaly at gmail.com> wrote in message 
>>>> news:MPG.23615f5e560d4d3f989763 at news.digitalmars.com...
>>>>> Wed, 15 Oct 2008 21:12:31 -0400,
>>>>> Steven Schveighoffer wrote:
>>>>>> "bearophile" <bearophileHUGS at lycos.com> wrote in message
>>>>>> news:gd63sv$2j0t$1 at digitalmars.com...
>>>>>>> Steven Schveighoffer:
>>>>>>>> I think this can be solved even simpler.  Make string literal type 
>>>>>>>> be
>>>>>>>> invariant(char)[] instead of static array.  It does not need to be 
>>>>>>>> on the
>>>>>>>> heap.  That would solve lots of IFTI problems too.
>>>>>>> With your idea this syntax:
>>>>>>> auto a = ["Hello", "what"];
>>>>>>> Gives a fixed-sized array of invariant(char)[]. I think that's 
>>>>>>> asymmetric.
>>>>>>> My suggestion works with all arrays, so the array 'a' too becomes/is
>>>>>>> dynamic, keeping the simmetry.
>>>>>> Sure, make the type dynamic for all array literals.  My issue is with 
>>>>>> your
>>>>>> proposal to make the data allocated on the heap.
>>>>>>
>>>>>> There is no need for an array literal to be typed as a static array. 
>>>>>> Ever.
>>>>> I can see one need, matrix literals:
>>>>>
>>>>> auto blah =
>>>>> [
>>>>>  [ 1,  0,  0 ],
>>>>>  [ 0,  0, -1 ],
>>>>>  [ 0, -1,  0 ]
>>>>> ];
>>>>>
>>>>> so that blah is a sequence of 9 numbers accessed accordingly, not 3
>>>>> arrays of arbitrary length each.
>>>>>
>>>>> Well, it's probably a special case and deserves a special, safer 
>>>>> syntax.
>>>> Just don't use auto:
>>>>
>>>> int[3][3] blah = ...
>>>>
>>>> Make it clear your intention.  A literal should follow the most common 
>>>> usage, and leave the corner cases to specific syntax.  Most people 
>>>> don't use static arrays when working with literals.  The most common 
>>>> usage of static arrays I've seen is to establish a buffer on the stack:
>>>>
>>>> byte[1000] buf = void;
>>> Walter wanted to do things that way. I wanted to implement things the 
>>> T[auto] way. The problem with specifying size twice is that there are 
>>> two points of maintenance. If the language can help, why not?
>>>
>>> Andrei
>>
>> Yes, good point.
>>
>> What about using static, there's a keyword that screams out 'this is 
>> static' :)
>>
>> byte[static] = [0,1,2];
>>
>> or
>>
>> auto[static] = [0,1,2]; // typed as int[3]
>>
>> T[auto] could look like you are trying to declare an AA with the key type 
>> being inferred.  But of course, that's probably very rare.
>>
>> Just playing around ;)  No idea if people would like that syntax, static 
>> is already heavily overloaded.
>
> T[$] was also suggested.
>

I like T[static] a lot. Static might be a highly overloaded word, but the 
idea of a "static array" is already one of the firmly established overloads. 
You want a static array? Say "static". Nice :)

I thought the exact same thing about T[auto], but didn't say anything. It 
really does make me think "AA of an inferred keytype". Which might not be a 
bad feature to have, actually.

T[$] is too much meaning-overloading. A $ inside of square brackets already 
means "length". Using it in this way is completely different. Almost looks 
like a deliberate "buffer overflow"-type ;)