static array literal syntax request: auto x=[1,2,3]S;

[Timon Gehr]

On 06/10/2012 04:54 PM, Artur Skawina wrote:
> On 06/10/12 10:47, mta`chrono wrote:
>> Am 10.06.2012 01:02, schrieb Timon Gehr:
>>> On 06/10/2012 12:34 AM, Jonathan M Davis wrote:
>>>> On Sunday, June 10, 2012 00:15:01 Timon Gehr wrote:
>>>>> D static array literals don't perform a costly heap allocation. It is
>>>>> simply a bug in the implementation. This is not a compelling reason to
>>>>> add new syntax.
>>>>
>>>> D
>>>
>>> DMD
>>>
>>>> doesn't _have_ static array literals. It only has dynamic array literals.
>>>>
>>>> int[5] a = [1, 2, 3, 4, 5];
>>>>
>>>
>>> This is a static array literal.
>>>
>>>> should definitely be optimized such that it doesn't do any heap
>>>> allocations,
>>>> but the array literal itself is dynamic regardless, as typeof indicates.
>>>
>>> I don't see a typeof there. The array literal is a static array literal
>>> if it is assigned/converted to a static array.
>
> An array literal is a dynamic array with a known constant length that
> implicitly converts to a static array of the same size and element type.
> That's a sane definition,

It is not. It does not specify if/when allocations take place, for example.

> and AFAICT this is how it's currently handled.
>

It is not.

void main(){
     int[0] x = [1];
}


>>>> The
>>>> other place that this causes problems is templated functions. e.g.
>>>>
>>>> void func(A)(A array)
>>>>       if(isStaticArray!A)
>>>> {}
>>>>
>>>> func([1, 2, 3, 4, 5]);
>>>>
>>>> will fail to compile. You're forced to create one on the stack first.
>>>>
>>>> int[5] array = [1, 2, 3, 4, 5];
>>>> func(array);
>>>>
>>>
>>> func(cast(int[5])[1,2,3,4,5]);
>>>
>>>> That _might_ merit adding a syntax for indicating that an array
>>>> literal is
>>>> static.
>
> I wasn't kidding about overloading 'static' for this; it would certainly
> be better that inventing yet another literal syntax.
>

Using 'static' is "inventing yet another literal syntax" as well.

>>> Yes, certainly. I was simply pointing out that arguing about performance
>>> makes a poor case here.
>>>
>>>> However, in general, it's definitely true that the additional heap
>>>> allocations
>>>> that we currently see should just be optimized out by the compiler,
>>>> and if
>>>> that's all that we're trying to solve, then that's a matter of fixing the
>>>> optimizer, not the language.
>>>>
>>>
>>> This is not about optimization. Allocating is simply incorrect. It is a
>>> 'wrong code' bug.
>>
>> Yes, you're right. And you've also shown that we don't need a new syntax
>> to accomplish this.
>
> When you want to avoid the heap allocation, you can always use hacks such as:
>
>     template static_array(alias da) {
>        typeof(da[0])[da.length] static_array = da;
>     }
>     f(...) {
>        int[3] a = static_array!([1,2,3]);
>        ...
>     }
>
> But the compiler should do this automatically in these cases,

The compiler should do the right thing, not automatically apply a hack 
that only works for CTFEable right hand sides.

> right now it
> doesn't. This hack won't of course work for the program mentioned in this
> thread.
>
> The isStaticArray!A problem is partially related to how the compiler handles
> arrays.
>
>     auto f(T)(T a) { enum l = a.length; return l; }
>
> works with
>
>     int[3] a = [1,2,3];
>     f(a);
>
> but fails with
>
>     f([1,2,3]);
>
> And cases like
>
>     auto f(E)(E[] a) { enum l = a.length; return l; }
>
> don't work at all.
>
> Making these things work, which should be possible,

f([1,2,3]);               // f!(int[])
f([1,2,3,4]);             // f!(int[])

int[3] a = [1,2,3];
f(a);                     // f!(int[3])
f(cast(int[3])[1,2,3]);   // f!(int[3])
f(cast(int[4])[1,2,3,4]); // f!(int[4])

> would help when dealing
> with static arrays, and also allow more optimization opportunities.
>
> artur

I don't see it helping optimization.