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

[d-bugmail at puremagic.com]

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



--- Comment #4 from Steven Schveighoffer <schveiguy at yahoo.com> 2010-09-17 09:18:52 PDT ---
(In reply to comment #3)
> Answer to comment2:
> 
> I understand what you say only partially. In my opinion silently ignoring the
> opCmp() and toHash() like in my first example is not acceptable for the D
> language (that was a bug in my code).

But those are valid functions.  Why should the D compiler refuse to compile
them?  See my point about opEquals.  This is probably a job for a lint-type
tool.  To have the compiler assume what you are thinking can be just as bad, in
fact even worse, than blindly obeying your instructions.

> The general design of D is to perform safe things on default, and unsafe on
> request. And here the safer thing is to perform the conformance tests on
> default and disable them on request. I agree that an attribute is better here.
> So a @notypeinfo seems better, if it's implementable and useful.

This has nothing to do with memory safety, which is what safe D is all about. 
opCmp and friends are first of all functions, with all the flexibility that
functions enjoy.  These kinds of problems occur in many places where duck
typing is used.  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?

Note that opCmp can legitimately take all kinds of arguments, and legitimately
not be const.

One possible solution for this is to get rid of the runtime-properties all
together, and just use templates/duck typing fully.  Then you get a
compile-time error when you define it improperly and use it in something like
an AA or sort.

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