http://d.puremagic.com/issues/show_bug.cgi?id=3433
--- Comment #7 from Don <clugd...@yahoo.com.au> 2009-11-14 12:22:30 PST --- (In reply to comment #6) > (In reply to comment #5) > > This has some tricky points. The first is that it's recursive. As well as > > structs, it also applies to fixed-length arrays: if either contains a struct > > with an opEquals, the entire struct must be compared member-by-member; and > > this > > check must be performed recursively. > > Correct - more precisely, transitive for direct fields. I think the comparison > should simply call a template object.structCompare that we define as a library > function. I'm pretty sure the compiler can just translate it into (x.field1==y.field1 && x.field2==y.field2 && ...) if any field has an opEquals(). This is recursive: so any struct fields which don't have opEquals() can simply use bitwise comparison as now. The recursion doesn't apply to classes; if it doesn't have opEquals(), it's bitwise regardless of what its members do. I guess this is what you mean by direct fields. > > The third difficult part relates to protection. Any of the struct members > > may > > be private and defined in a different module. > > > > If a field in the struct is a class, it probably applies to it as well. > > I'm not sure how to address this. I have now got this successfully detecting the cases where it needs to use member-by-member comparison for the cases above. I'll add an error for the union case. I don't yet have a solution to the protection issue. Obviously it can done by suppressing any protection errors which occur, but I hope it can be done without a compiler hack. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------