Issue 1974 - What's your opinion?

[Jonathan M Davis]

On Thursday, October 24, 2019 4:09:52 AM MDT Walter Bright via Digitalmars-d 
wrote:
> On 10/24/2019 1:02 AM, RazvanN wrote:
> > I guess that what could be implemented is something along the lines of:
> > if the opAssign/op*Assign function is pure, then you can error/warn
> > because the call has no effect, otherwise it is possible that the
> > assign function has side effects so calling it is correct."
>
> Warnings are problematic - is the code correct or not? We should avoid
> them and just decide if it is an error or not.
>
> It's not so simple that if it's pure, it should be an error. For example,
> pure functions can throw exceptions. Then you're into if it's pure and
> nothrow, then it should be an error. But then the rule might just be too
> clever, and just make the language harder to learn.
>
> Language rules are better when they are orthogonal, and giving errors on
> vacuous code make it not orthogonal causes other problems. See the
> discussion on what to do about unreachable code errors with:
>
>      int test() {
>         static if (1) return 3;
>         return 1;
>      }
>
> I'd suggest leaving the behavior as is and mark the issue invalid.

And even if the function were pure and nothrow, it wouldn't be enough,
because both the argument and the object being assigned to could have
references to other data that opAssign then mutates. I'm not sure if there
are really any valid reasons to something like that in opAssign - especially
when it's done on a temporary - but we can't guarantee that nothing like
that is happening unless the functions is strongly pure and nothrow (and you
can't have opAssign be strongly pure, because then you couldn't actually
mutate the object).

I think that the only way that it would make sense to disallow the assigment
would be to just flag it prior to the lowering based on the fact that it's a
temporary (and I have no clue how easy that would be to do) with the idea
that it makes no sense to assign to a temporary, but I'm not sure that it's
enough a problem to be worth worrying about. Regardless, I completely agree
that we shouldn't be special casing things here based on how a particular
opAssign is implemented - especially since it clearly doesn't buy us enough
here to be worth the confusion that it would almost certainly cause.

- Jonathan M Davis