Regarding recent discussions in Bugzilla: I wonder if we could somehow define
a super-efficient struct opEquals that performs introspection and only tests
expensive members if it's necessary. For example, here is a simple case of it:
enum opEqualsMixin = q{
bool opEquals(typeof(this) rhs) {
dsimcha:
> Similar stuff could be done for a generic opCmp that gives a
> struct an arbitrary total ordering as long as all of its members have a total
> ordering.
I have a similar structCmp in my dlibs, it's used by the Record/record (similar
to the Tuple/tuple of Phobos2). It works recursively
dsimcha wrote:
Regarding recent discussions in Bugzilla: I wonder if we could somehow define
a super-efficient struct opEquals that performs introspection and only tests
expensive members if it's necessary. For example, here is a simple case of it:
enum opEqualsMixin = q{
bool opEquals(typ
dsimcha wrote:
Regarding recent discussions in Bugzilla: I wonder if we could somehow define
a super-efficient struct opEquals that performs introspection and only tests
expensive members if it's necessary.
The compiler should be doing this. It's the way to fix the Bugzilla bug.
There should b
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> > Of course, we could get even fancier. We could recursively introspect
> > struct
> > types and use various heuristics to calculate the optimal comparison order
> > at
> > compile time. Similar stuff could be done fo
Don wrote:
Yes. This is something the compiler can't (or shouldn't) do.
It shouldn't do it. If a memberwise compare is done, it should do them
in order. This allows the struct designer to lay out the fields
optimally (similarly to how case statement order affects efficiency in
switch stateme
