[Issue 4290] 'Fragile' opCmp/toHash signature errors

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4290



--- Comment #5 from bearophile_hugs at eml.cc 2010-09-20 05:25:27 PDT ---
> Why should the D compiler refuse to compile them?

The D compiler has to disallow or warn against common traps.


> This is probably a job for a lint-type tool.

If some bug may be found at compile-time and it's not too much hard to find it
(example: it doesn't require flow analysis), then in my opinion it's a job of
the (D) compiler to avoid the bug. Clang compiler designers seem to agree with
me.


> This has nothing to do with memory safety, which is what safe D is all about. 

I was not talking about memory safety or SafeD, I was talking about code safety
in general. Generally D needs to be designed to avoid common bugs, when
possible (another example of bug that I'd like D to avoid is to accept strings
like "<<>" as operators for the operator overloading string template).


> For example, you can mis-define some range by doing something
> like popfront().  The compiler won't refuse to compile this, and shouldn't. 
> But it will refuse to allow it to be passed into a range-accepting function. 
> Where do we draw the line?

That's a nice example. I don't have a generic answer for your question, but to
let this function be accepted and silently ignored:
int opCmp(ref const Foo f) {
because this is the only correct one:
int opCmp(ref const Foo f) const {
is too much bug-prone, in my opinion. This is beyond the line for me.

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