http://d.puremagic.com/issues/show_bug.cgi?id=9732
--- Comment #8 from monarchdo...@gmail.com 2013-03-17 09:48:36 PDT --- (In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #1) > > > The problem is that opAssign can perform deep copy operations for which > > > blitting isn't enough. > > > > That's why we have postblit. If anything, I'd expect postblit to be safer > > then > > opAssign: postblit has no pre-state, whereas opAssign may make assumptions > > about it's current (run-time initialized?) state. > > Postblit does not cover cases when object assigned to struct is of different > type - this is main purpose of overloading opAssign in addition to defining > postblit. Yes, but if the types don't match, then the discussion we're having here is irrelevant: The only way to avoid a call to opAssign is if the types match, in which case you can postblit. > Making assumptions about state of object on entering postblit and opAssign is > very risky, you can effectively receive garbage. Yes, but when you postblit, you only have to worry about the state of the "rhs" object, since the "lhs" object has no prior state. With opAssign, you may have to worry about the state of the currently being assigned to object. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
