https://issues.dlang.org/show_bug.cgi?id=11920

--- Comment #2 from monarchdodra@gmail.com ---
I re-encountered this problem with this new usecase. That code don't make no sense to me:

//----
struct S
{
    int i;
}
enum a = [1, 2, 3];
enum b = S(1);

void foo(ref int b)
{
    b = 5;
}

void main()
{
    foo(a[1]);
    foo(b.i);
}
//----

--

https://issues.dlang.org/show_bug.cgi?id=11920

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unspecified                 |D2

--

https://issues.dlang.org/show_bug.cgi?id=11920

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

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

--- Comment #3 from RazvanN <razvan.nitu1305@gmail.com> ---
https://github.com/dlang/dmd/pull/9023

--

https://issues.dlang.org/show_bug.cgi?id=11920

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> ---
Have to be careful, because we want things like this to work:

   void bar(ref T t);
   T foo();

   foo().bar()

--

https://issues.dlang.org/show_bug.cgi?id=11920

--- Comment #5 from Andrei Alexandrescu <andrei@erdani.com> ---
@Walter are you sure? You code does not work today.

--

https://issues.dlang.org/show_bug.cgi?id=11920

--- Comment #6 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to Andrei Alexandrescu from comment #5)
> @Walter are you sure? You code does not work today.

I seem to recall that this has been discussed at length in the past, and the consensus was that it should work.

I'm surprised that it apparently was never implemented.

Clearly, this issue needs some investigation.

--

https://issues.dlang.org/show_bug.cgi?id=11920

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |atila.neves@gmail.com

--- Comment #7 from RazvanN <razvan.nitu1305@gmail.com> ---
*** Issue 19507 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=11920

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com

--- Comment #8 from Basile-z <b2.temp@gmx.com> ---
It's actually specified to be a lvalue:

> The following expressions, and no others, are called lvalue expressions or lvalues:
>
> [...]
>
> the result of the . PostfixExpression or Module Scope Operator when the rightmost side of the dot is a variable, field (direct or static), function name, or invocation of a function that returns by reference;

https://dlang.org/spec/expression.html#.define-lvalue

--

https://issues.dlang.org/show_bug.cgi?id=11920

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |scienticman@gmail.com

--- Comment #9 from Basile-z <b2.temp@gmx.com> ---
*** Issue 22290 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=11920

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick@geany.org

--- Comment #10 from Nick Treleaven <nick@geany.org> ---
With dmd v2.106.0-rc.1, inside @safe and with -dip1000:

    foo().i = 5; // still allowed
    int* p = &foo().i; // error, address assigned to longer lived variable

Comment #3:

    foo(a[1]); // still allowed, should fail
    foo(b.i); // error, cannot pass rvalue, same for comment #4

--