www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3969] New: Built-in compile time errors against usage of wrong operator strings

reply d-bugmail puremagic.com writes:
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 puremagic.com
        ReportedBy: bearophile_hugs eml.cc



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: -------
Mar 15 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3969


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com
           Platform|Other                       |All
            Version|2.041                       |D2
         OS/Version|Windows                     |All
           Severity|normal                      |enhancement


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 30 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3969


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com



15:37:13 PST ---
We can collect all legal operators for opUnary, opBinary, etc, and statically
reject those which aren't legal. However I think this can only work for simple
cases, e.g.:

bool opBinary(string op : "==", T)(T t)

bool opBinary(string op, T)(T t) if (op == "==")

bool opBinary(string op, T)(T t) if (isOpEquals!op)

The 1st case is easy and doable.

The 2nd case might be doable, but it depends on how complex the expression is.

The 3rd case is off-hands, because there's no telling what isOpEquals does
internally - or rather it could be hugely expensive to do anaylsis on the
template instance.

So is it worth having? I'm very fond of the idea personally, at least for case


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3969






 However I think this can only work for simple cases, e.g.:
I agree it can't work for all cases.
 So is it worth having? I'm very fond of the idea personally, at least for case

Is it worth having a not complete error reporting feature? Generally we want an error reporting to work in all cases, so the programmer can rely on it. On the other hand what's really important for an error is to be reliable, this means no false positives. I think in this case it's possible to avoid all false positives, the presence of some inevitable false negatives. And I think the code of a new D programmer is mostly of cases 1 and 2, that are the simpler to detect. So I think this feature is worth having. If in future D will add some more user defined operators (like a needed second multiplication useful for matrix multiplications), it will probably easy enough to extend and fix this error reporting. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 20 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3969


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
         AssignedTo|nobody puremagic.com        |andrej.mitrovich gmail.com



11:44:42 PST ---
Initial implementation which will probably see further improvement before it
gets pulled (or even a rejection.. you never know):

https://github.com/D-Programming-Language/dmd/pull/1398

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 22 2012