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

[Timon Gehr]

On 06/10/2012 07:00 PM, Artur Skawina wrote:
> On 06/10/12 18:02, Timon Gehr wrote:
>> On 06/10/2012 04:54 PM, Artur Skawina wrote:
>>> ...
>>> 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.
>
> Implementation details. Would you like to forbid "unnecessary" allocations?
> Not doing this should be harmless as it only affects performance,

Wrong.

class S{
     ~this() {
         int[3] a = [1,2,3];
     }
}


> but maybe
> the hidden heap allocations should indeed be disallowed. Any decent compiler
> won't be emitting them anyway.
>
>>> and AFAICT this is how it's currently handled.
>>>
>>
>> It is not.
>>
>> void main(){
>>      int[0] x = [1];
>> }
>
> Try running that, in non-release mode. :)
>

(I never post valid D code that I haven't run.)

> The fact that the compiler accepts it even in the cases where it should
> be able to statically figure out that it will fail at runtime isn't ideal,
> but this is just a quality of implementation issue.
>

It is a bug. A static type system is pointless if it is not used for 
validating certain code properties.

>
>>>>>> 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.
>
> In a way - yes. But i think "static[...]" would be much better than "[...]S".
>

Obviously, none is much better than the other.

> ...
>>>
>>> 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])
>
> I'm not sure what your point is here.

A statically known length cannot be different in two identical 
instantiations.

> Mine is that 'length' is
> known in all these cases at compile time. Yet it's only possible
> to retrieve it when the argument is a real static array. It should
> also be possible when the function is called with a literal.

That is a case for introducing a dedicated static array literal syntax, 
not for butchering the template instantiation semantics. (if at all)

> Yes,
> it's just for templates and would need (hidden) specialization/cloning.
> Which sounds worse than it is - because it can happen after inlining.
>

It sounds bad because it is bad.

>
>>> would help when dealing
>>> with static arrays, and also allow more optimization opportunities.
>
>> I don't see it helping optimization.
>
> See above.
>
> artur

The optimizer can inline the call and use the additional information 
gained without language changes.

What you want to achieve is better left to macros.