[Issue 3969] New: Built-in compile time errors against usage of wrong operator strings
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Mon Mar 15 10:47:03 PDT 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3969
Summary: Built-in compile time errors against usage of wrong
operator strings
Product: D
Version: 2.041
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: bearophile_hugs at eml.cc
--- Comment #0 from bearophile_hugs at eml.cc 2010-03-15 10:47:02 PDT ---
This D2 code runs:
struct Foo {
int data;
bool opBinary(string Op:"==")(ref const Foo other) { // wrong: opEquals
return this.data == other.data;
}
bool opBinary(string Op)(ref const Foo other) if (Op == "0") { // wrong
return this.data == other.data;
}
}
void main() {}
But that can cause bugs: it's easy for programmers to forget to use opEquals
instead of opBinary("==").
And generally I'd like dmd to raise an error when silly ops are defined, like
that "0". It's important to avoid many bugs in the operator overloading usage.
---------
Steven Schveighoffer>These kinds of errors are appropriate for a lint tool.<
Generally any compiler error can be moved to a lint tool, so it's a matter of
balance. In my opinion generally if some sanity test on the code is
computationally heavy or the errors it spots are uncommon, or if it's not
certain they are really errors, or if it's very uncommon, then it's possible or
better to move it to a lint. If the test is not hard/heavy to do and it can
catch a common sure mistake then it's better to put it into the compiler. D
compiler already performs several tests that were work for C lint tools.
So I think the compiler can be allowed to catch some potentially common
operator overloading bugs like opBinary("==").
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list