On Wed, Mar 20, 2013 at 01:17:13AM +0100, Dan wrote: > On Tuesday, 19 March 2013 at 23:13:19 UTC, Jonathan M Davis wrote: [...] > >But the main problem that I'm pointing out is that you can't define > >your own, non-standard functions for equality or hashing or whatever > >and expect your types to play nicely with other stuff. If your stuff > >is wrapped in types that do define the proper functions for that > >(like in your example), then it can work, but the types which were > >wrapped won't play nice outside of the wrapper. > > > > This is true, but then my code is by definition not standard. > However, theoretically, the language writers could. For example, any > '==' could be lowered to a 'standard' function, probably better named > 'intancesDeepEqual(a,b)' and that function could use reflection to > provide equal when not available else call opEquals if it is > available. Similar with opCmp, dup, idup, ... In other words, in the > vein of the original poster, why not allow all of these nice goodies > (equality comparison, opCmp comparison, dup) without requiring > boilerplate code while still honoring/using it when it is provided. [...]
I like this idea. By default, provide something that recursively compares struct/class members, array elements, etc.. But if at any level an opEquals is defined, then that is used instead. This maximizes convenience for those cases where you *do* just want a literal equality of all sub-structures, but also allows you to override that behaviour if your class/struct needs some other special processing. T -- "How are you doing?" "Doing what?"
