http://d.puremagic.com/issues/show_bug.cgi?id=4290
--- Comment #5 from bearophile_h...@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: -------