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

[d-bugmail at puremagic.com]

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



--- Comment #8 from Kevin Bealer <kevinbealer at gmail.com> 2010-09-20 20:04:28 PDT ---
I think when you are defining opCmp, it's a bit like overriding a function
signature, therefore, if D tries to prevent function hijacking, it makes
perfect sense for it to do the same thing here.

I have no problem with an enforced single interface for opCmp and opEquals and
so on.  I have no problem with having flexible interfaces where const or ref is
optional and up to the user.  I think either of these will work -- and I prefer
the second, actually.  Flexible is good, so long as it is practical to
implement.

But for the compiler to correctly generate code that calls the flexible API
(pick any signature you like) for opCmp when "<" is used, but does not call it
at all when ".sort" is used unless the signature matches a hidden template?

Come on, it can't really be meant to work like that, right?  It doesn't make
sense for the language to have two different behaviors.  It's an inconsistency
that doesn't make any sense from a language or user point of view.

I do think that for value types the .sort and T[] behaviors are best done in
something like a template mechanism, semantically.  Classes can use the
Object.opCmp version but for struct and primitives it makes sense to fully and
automatically specialize the code and build that into the language.  (Or at
least call whichever opCmp is present.)

Kevin

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