December 19, 2018
https://issues.dlang.org/show_bug.cgi?id=18802

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
Actually, I think that the bug report might not be invalid. Although this used to work, its consistent that now it doesn't. What happens here:

1. When the D-style variadic function is defined : `this(string[] bars...)`,
the compiler sees it as `this(scope string[] bars)` and everytime it gets
called (i.e `Foo("a", "b", "c")`) it rewrites the call to match the function
definition (i.e.
 `Foo(["a", "b", "c"])). The  important thing here is that the documentation
specifies that the array may be constructed on the stack.

2. When `this.bars = bars` is semantically analyzed the reference to the possibly stack constructed array is passed to `this.bars` which has a longer lifetime. This is an unsafe operation, so it is not possible in a safe function.

Your slightly modified example:

struct Foo
{
    int* bars;
    @safe this(scope int* bars)
    {
        this.bars = bars;
    }
}


void main()
{
    int a;
    auto f = Foo(&a);
}

This code started issuing an error since 2.074, so I'm guessing the direction the compiler is heading is this one.

Note how the above code is almost identical to the one generated by the compiler in your original post:

struct Foo
{
    string[] bars;
    @safe this(scope string[] bars)
    {
        this.bars = bars;
    }
}

void main()
{
    auto f = Foo(["a", "b", "c"]);   // -> the string[] is on the stack
constructed
}

I suggest we close this as invalid.

--
December 19, 2018
https://issues.dlang.org/show_bug.cgi?id=18802

Tomáš Chaloupka <chalucha@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Tomáš Chaloupka <chalucha@gmail.com> ---
Thanks for thorough explanation.
Makes sense to work this way, so this should probably really be closed as
invalid.

--