Issue 1974 - What's your opinion?

Walter Bright newshound2 at digitalmars.com
Thu Oct 24 10:09:52 UTC 2019


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.


More information about the Digitalmars-d mailing list