On Friday, 5 July 2019 at 23:05:32 UTC, Jonathan M Davis wrote:
>> Yes, I was wondering why the compiler doesn't statically allocate it automatically as an optimization.
>
> It would have to be set up to store the literal somewhere else.

I was thinking the read-only data segment.

> Certainly, it can't just put it on the stack, because that risks it going out of scope and causing memory problems. It

It can do that with small-ish sized literals if they don't escape (-dip1000). I think Walter may have advocated something like this. This one can be done even with literals of mutable elements.

> no matter what optimizations the compiler does with array literals, that shouldn't affect whether the function can be @nogc. For it to affect that, it would have to be something that was guaranteed by the language's semantics regardless of whether any optimizations were being done.

Yes, just like string literals I think static allocation can be part of the language for immutable data.

On Saturday, 6 July 2019 at 09:56:57 UTC, ag0aep6g wrote:
> On 06.07.19 01:12, Patrick Schluter wrote:
>> On Friday, 5 July 2019 at 23:08:04 UTC, Patrick Schluter wrote:
>>> On Thursday, 4 July 2019 at 10:56:50 UTC, Nick Treleaven wrote:
>>>> immutable(int[]) f() @nogc {
>>>>     return [1,2];
>>>> }
> [...]
>> 
>> and it cannot optimize it away because it doesn't know what the caller want to do with it. It might in another module invoke it and modify it, the compiler cannot tell. auto a=f(); a[0]++;
>
> f returns immutable. typeof(a) is immutable(int[]). You can't do a[0]++.

You're right, I shouldn't post at 1 am.