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: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@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: -------