On 6/8/22 19:22, deadalnix wrote:
> On Wednesday, 8 June 2022 at 17:09:49 UTC, Mathias LANG wrote:
>> And you'll see the bug, even without `-preview=dip1000`.
>>
>> Why is this happening ? You correctly guessed, because the frontend wrongfully lets the `string` go on the stack instead of allocating with it.
>> ...

Your code is literally calling this function:

```d
string foo(scope string s){ return s; }
```

This causes UB, therefore you can't blame the compiler frontend here. I guess you can complain about the language specification, but what else are you expecting `scope` to do? There could be some more diagnostics I guess, like for the case where a stack variable is escaped directly.


>> Some of the changes for DIP1000 made it to releases even without the switch, that's one example.
> 
> No, promoting the array on stack is not sufficient to explain the behavior - thought it is certainly part of it.
> 
> The compiler is going out of his way in some other way to break the code.

It's reusing the same location on the stack for all instances of `[c]`. I think that's a pretty complete and straightforward explanation of the behavior. What is missing?

Anyway, this kind of issue is why one should never rely on undefined behavior giving a specific result; the compiler may get smart about it later.

On Wednesday, 8 June 2022 at 18:32:41 UTC, Timon Gehr wrote:
> On 6/8/22 19:22, deadalnix wrote:
>> On Wednesday, 8 June 2022 at 17:09:49 UTC, Mathias LANG wrote:
>>> And you'll see the bug, even without `-preview=dip1000`.
>>>
>>> Why is this happening ? You correctly guessed, because the frontend wrongfully lets the `string` go on the stack instead of allocating with it.
>>> ...
>
> Your code is literally calling this function:
>
> ```d
> string foo(scope string s){ return s; }
> ```
>
> This causes UB, therefore you can't blame the compiler frontend here.

I got to say here, you shouldn't be able to compile that code at all if it is going to shoot you in the foot unintentionally.

- Alex

On 6/8/22 20:44, 12345swordy wrote:
> On Wednesday, 8 June 2022 at 18:32:41 UTC, Timon Gehr wrote:
>> On 6/8/22 19:22, deadalnix wrote:
>>> On Wednesday, 8 June 2022 at 17:09:49 UTC, Mathias LANG wrote:
>>>> And you'll see the bug, even without `-preview=dip1000`.
>>>>
>>>> Why is this happening ? You correctly guessed, because the frontend wrongfully lets the `string` go on the stack instead of allocating with it.
>>>> ...
>>
>> Your code is literally calling this function:
>>
>> ```d
>> string foo(scope string s){ return s; }
>> ```
>>
>> This causes UB, therefore you can't blame the compiler frontend here.
> 
> I got to say here, you shouldn't be able to compile that code at all if it is going to shoot you in the foot unintentionally.
> 
> - Alex

Well, I agree that in simple cases like this one, the compiler should just complain. In general though, it won't understand what's going on. If you want to catch everything, you'll have to use @safe, but that will also reject some things that are actually fine.

On Wednesday, 8 June 2022 at 18:44:28 UTC, 12345swordy wrote:
> On Wednesday, 8 June 2022 at 18:32:41 UTC, Timon Gehr wrote:
>> On 6/8/22 19:22, deadalnix wrote:
>>> On Wednesday, 8 June 2022 at 17:09:49 UTC, Mathias LANG wrote:
>>>> And you'll see the bug, even without `-preview=dip1000`.
>>>>
>>>> Why is this happening ? You correctly guessed, because the frontend wrongfully lets the `string` go on the stack instead of allocating with it.
>>>> ...
>>
>> Your code is literally calling this function:
>>
>> ```d
>> string foo(scope string s){ return s; }
>> ```
>>
>> This causes UB, therefore you can't blame the compiler frontend here.
>
> I got to say here, you shouldn't be able to compile that code at all if it is going to shoot you in the foot unintentionally.
>
> - Alex

I believe this is because foo is not annotated with @safe, thus it's @system by default and you're allowed to do all kinds of unsafe things. Mark it @safe and the compiler will correctly complain:

```
@safe
string foo(in string s)
{
    return s; // Error: scope variable `s` may not be returned
}

void main()
{
    import std.stdio;
    string[] result;
    foreach(c; "hello")
    {
        result ~= foo([c]);
    }
    writeln(result);
}
```

In addition, changing `in` to `const return scope` makes the compiler aware that you intend to return the value, and thus it seems to somehow know not to re-use that stack space, and correctly prints ["h", "e", "l", "l", "o"].