On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:
>> A slice of a no-longer-existing temporary! Admittedly, this is not an issue with your code, but a deeper issue of allowing slicing of rvalues.
> This works:
> ----
> int[] as = [1, 2, 3].s;
> writeln(as[2]);

Of course this slice is only valid as long as you dont leave the scope. That's maybe what you tried to say, right?

On 5/2/16 3:02 PM, Namespace wrote:
> On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:
>>> A slice of a no-longer-existing temporary! Admittedly, this is not an
>>> issue with your code, but a deeper issue of allowing slicing of rvalues.
>> This works:
>> ----
>> int[] as = [1, 2, 3].s;
>> writeln(as[2]);
>
> Of course this slice is only valid as long as you dont leave the scope.
> That's maybe what you tried to say, right?

No, because 'as' is pointing at stack space no longer allocated. It may work, and it may not, but having it work is not proof that it's sound.

To make things clear, this is what your code effectively does:

int[] as = void;
{
   auto _tmp = [1, 2, 3].s;
   as = _tmp;
}

Which is not the same thing as having the static array a defined stack variable in the same scope.

-Steve

On Monday, 2 May 2016 at 19:08:52 UTC, Steven Schveighoffer wrote:
> On 5/2/16 3:02 PM, Namespace wrote:
>> On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:
>>>> A slice of a no-longer-existing temporary! Admittedly, this is not an
>>>> issue with your code, but a deeper issue of allowing slicing of rvalues.
>>> This works:
>>> ----
>>> int[] as = [1, 2, 3].s;
>>> writeln(as[2]);
>>
>> Of course this slice is only valid as long as you dont leave the scope.
>> That's maybe what you tried to say, right?
>
> No, because 'as' is pointing at stack space no longer allocated. It may work, and it may not, but having it work is not proof that it's sound.
>
> To make things clear, this is what your code effectively does:
>
> int[] as = void;
> {
>    auto _tmp = [1, 2, 3].s;
>    as = _tmp;
> }
>
> Which is not the same thing as having the static array a defined stack variable in the same scope.
>
> -Steve

The assembler looks different than that but I may be wrong and I only looked at gdc.
But anyway, that means with 'pragma(inline, true)' I'm save. Is that right?

On 5/2/16 3:12 PM, Namespace wrote:
> On Monday, 2 May 2016 at 19:08:52 UTC, Steven Schveighoffer wrote:
>> On 5/2/16 3:02 PM, Namespace wrote:
>>> On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:
>>>>> A slice of a no-longer-existing temporary! Admittedly, this is not an
>>>>> issue with your code, but a deeper issue of allowing slicing of
>>>>> rvalues.
>>>> This works:
>>>> ----
>>>> int[] as = [1, 2, 3].s;
>>>> writeln(as[2]);
>>>
>>> Of course this slice is only valid as long as you dont leave the scope.
>>> That's maybe what you tried to say, right?
>>
>> No, because 'as' is pointing at stack space no longer allocated. It
>> may work, and it may not, but having it work is not proof that it's
>> sound.
>>
>> To make things clear, this is what your code effectively does:
>>
>> int[] as = void;
>> {
>>    auto _tmp = [1, 2, 3].s;
>>    as = _tmp;
>> }
>>
>> Which is not the same thing as having the static array a defined stack
>> variable in the same scope.
>>
>
> The assembler looks different than that but I may be wrong and I only
> looked at gdc.
> But anyway, that means with 'pragma(inline, true)' I'm save. Is that right?

The assembler might be safe in some instances, but that doesn't reflect the original internal representation in the compiler. Some other configuration of calls may allow the compiler to reuse that memory, and then you run into problems.

I'm wondering if you used my rewrite if it would actually output the same thing?

But in any case, I don't know the answer to the pragma(inline) thing. I would guess it is subject to the same issues, but I'm not 100% sure.

-Steve

> The assembler might be safe in some instances, but that doesn't reflect the original internal representation in the compiler. Some other configuration of calls may allow the compiler to reuse that memory, and then you run into problems.
>
> I'm wondering if you used my rewrite if it would actually output the same thing?

Not quite. Look for yourself:
https://godbolt.org/g/kO8hdW
https://godbolt.org/g/KCfYPy

On 5/2/16 3:38 PM, Namespace wrote:
>> The assembler might be safe in some instances, but that doesn't
>> reflect the original internal representation in the compiler. Some
>> other configuration of calls may allow the compiler to reuse that
>> memory, and then you run into problems.
>>
>> I'm wondering if you used my rewrite if it would actually output the
>> same thing?
>
> Not quite. Look for yourself:
> https://godbolt.org/g/kO8hdW
> https://godbolt.org/g/KCfYPy

Except for offsets, it looks identical. May be the compiler puts things in different spots for different ways of writing.

But the thing that's not disclosed here is: what happens when the compiler feels the need to reuse that stack space? Your example doesn't have anything that may compete for the space, it just returns after this is over.

For example, define a static array of exactly the same size to use after the call:

int[3] x;

Now, see if x is pigeonholed into that same place your temporary return existed (and therefore 'as' points at it).

I'm still fully on the side of this being unsafe.

-Steve

On Monday, 2 May 2016 at 20:05:15 UTC, Steven Schveighoffer wrote:
> On 5/2/16 3:38 PM, Namespace wrote:
>>> The assembler might be safe in some instances, but that doesn't
>>> reflect the original internal representation in the compiler. Some
>>> other configuration of calls may allow the compiler to reuse that
>>> memory, and then you run into problems.
>>>
>>> I'm wondering if you used my rewrite if it would actually output the
>>> same thing?
>>
>> Not quite. Look for yourself:
>> https://godbolt.org/g/kO8hdW
>> https://godbolt.org/g/KCfYPy
>
> Except for offsets, it looks identical. May be the compiler puts things in different spots for different ways of writing.
>
> But the thing that's not disclosed here is: what happens when the compiler feels the need to reuse that stack space? Your example doesn't have anything that may compete for the space, it just returns after this is over.
>
> For example, define a static array of exactly the same size to use after the call:
>
> int[3] x;
>
> Now, see if x is pigeonholed into that same place your temporary return existed (and therefore 'as' points at it).
>
> I'm still fully on the side of this being unsafe.
>
> -Steve

I used it very often, but always assigned the result to an auto-type variable, never to a slice.

On 5/2/16 4:14 PM, Namespace wrote:

> I used it very often, but always assigned the result to an auto-type
> variable, never to a slice.

Using auto is fine, but the slice should not happen if you are assigning slice to a local var. There is a bug report on this: https://issues.dlang.org/show_bug.cgi?id=12625, though it's not as focused as I think it should be.

-Steve

On Monday, 2 May 2016 at 17:43:56 UTC, Namespace wrote:
>
> I still like
> ----
> auto s(T, size_t n)(T[n] arr) {
> 	return arr;
> }

Wooah, this trick is awesome. But actually it does the same thing that what I've proposed before. Exactly the same code is generated. So I'd say that it's rather a matter of readability.

https://godbolt.org/g/wGTs52
https://godbolt.org/g/cXECyO

On Monday, 2 May 2016 at 17:43:56 UTC, Namespace wrote:
> immutable auto a  = [1,2,3].s;

Will that have zero run-time overhead compared to:

    immutable int[3] a = [1,2,3];

?