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