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