recursive equal, and firstDifference functions

[H. S. Teoh]

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?"