string foo(in string s)
{
    return s;
}

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

With no previews, preview=dip1000, or preview=in, this outputs: ["h", "e", "l", "l", "o"]

With both preview=dip1000 and preview=in, this outputs: ["o", "o", "o", "o", "o"]

What is happening is the compiler is somehow convinced that it can allocate the array literal on the stack (and overwrites that literal each loop).

I know this isn't @safe code, but @system code shouldn't be made less safe by the preview switches!

I know people write in instead of const all the time simply because it's shorter.

Thoughts?

-Steve

On Wednesday, 8 June 2022 at 14:52:53 UTC, Steven Schveighoffer wrote:

string foo(in string s)
{
    return s;
}

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

This is simply the result of using in wrong. in means const scope. scope (without preceeding return) means you won't return a reference to the address to the argument (unless the function can reach it via some other channel). Result: undefined behaviour.

On 6/8/22 11:10 AM, Dukc wrote:

string foo(in string s)
{
    return s;
}

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

So silently changing behavior to create new dangling pointers with a preview switch is ok?

Remember, there is already code that does this. It's not trying to be clever via scope, it's not trying to be @safe, it's expecting that an array literal is allocated on the GC (as has always been the case).

-Steve

On Wednesday, 8 June 2022 at 15:35:56 UTC, Steven Schveighoffer wrote:

string foo(in string s)
{
    return s;
}

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

The preview switch is changing the meaning of in which changes the signature of foo (which is then inconsistent with the implementation), which in turn will affect the call sites. This seems roughly as expected, no?

On Wednesday, 8 June 2022 at 15:58:10 UTC, John Colvin wrote:

E.g. this prints ["o", "o", "o", "o", "o"] regardless of compiler flags

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

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

On Wednesday, 8 June 2022 at 16:01:55 UTC, John Colvin wrote:

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

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

There is no frame of reference in which this result is in any way reasonable.

On 6/8/22 11:58 AM, John Colvin wrote:

I guess it is! I always thought in meant const scope, but apparently it no longer does unless you add -preview=in. However, I will note that just using -preview=in does not cause it to print the o strings, only when paired with dip1000 does it do that.

Still, I would think a warning, even for @system code is warranted. Especially since the compiler is already able to figure this out for @safe code.

The reality is that people are (mostly) only dealing with the existing implementation, until it stops working. But to silently break it, and silently break it with memory corruption does not seem an appropriate penalty.

-Steve

On Wednesday, 8 June 2022 at 16:16:37 UTC, deadalnix wrote:

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

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

Yeah, shouldn't the compiler complain that s is trying to escape the scope of foo?

On Wednesday, 8 June 2022 at 16:16:37 UTC, deadalnix wrote:

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

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

My guess is that technically foo has undefined behaviour.