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

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@erdani.com

--- Comment #1 from Andrei Alexandrescu <andrei@erdani.com> ---
Eyal, what do you think should be the right behavior? I think we should never allow partial assignment, i.e. do not use any alias this logic on the left hand side.

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

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

--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> ---
I agree with Andrei. The slicing behavior is certainly surprising, it should be an error.

--

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

--- Comment #3 from Eyal <eyal@weka.io> ---
Agreed. Assignment should assign the whole thing.

--

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

--- Comment #4 from Andrei Alexandrescu <andrei@erdani.com> ---
Great you guys. I think it's best to qualify this as an wrong-code bug so we don't go through a deprecation cycle. OK?

--

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

Stefan Koch <uplink.coder@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uplink.coder@gmail.com

--- Comment #5 from Stefan Koch <uplink.coder@gmail.com> ---
(In reply to Andrei Alexandrescu from comment #4)
> Great you guys. I think it's best to qualify this as an wrong-code bug so we don't go through a deprecation cycle. OK?

What No?
That's changing semantics!

Comparison behaves the same.
I agree that this is annoying.
But for alias-this to work functions and fields which match the alias-this have
priority.

--

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

--- Comment #6 from Eyal <eyal@weka.io> ---
Stefan - under what circumstances does prioritizing "alias this" ever help?

Anyway, a compiler error - not changed semantics - as proposed here, should be
fine (with the ordinary caveat of __traits(compiles ...)).

Also, currently it may inconsistently choose to assign the outer or inner field in different circumstances, which is clearly the worst of all worlds.

Assignment *always* assigning the whole lvalue is easier to explain and far less error-prone.

--

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

--- Comment #7 from Stefan Koch <uplink.coder@gmail.com> ---
Eyal, I guess you could make it such that you error out if alias-this ever
conflicts with anything.
Which would be a solution that properly fixes unwanted overload-stealing.

However that'll break a lot of code, then again perhaps that is a good thing. I'd just ask for a spec change to clearify this.

To answer your question:

I don't remember the usecase anymore, which required alias-this to work the way it does, it might be a misconception on my part.

--

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

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

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

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

--

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

--- Comment #9 from Andrei Alexandrescu <andrei@erdani.com> ---
Talked to Razvan, and we're thinking of the following minimally disruptive change:

* If the struct has only ONE member of type T && the alias this yields a ref T
    pass
* Else
    issue a deprecation

This keeps legit cases working and disallows mistakes.

--

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

--- Comment #10 from anonymous4 <dfj1esp02@sneakemail.com> ---
AFAIK transparent wrappers rely on LHS alias this for assignment.

I think what shouldn't happen is triggering alias this on both sides of assignment at the same time. Should be fine if only one side uses it.

--