digitalmars.D.learn - Theory question
- BCS (22/22) May 21 2009 Are there any cases where the following cases both compile but are not i...
- Frits van Bommel (11/27) May 21 2009 struct A {
- BCS (4/34) May 21 2009 Oh, forgot opAssign (darn)
Are there any cases where the following cases both compile but are not identical? A a; B b; a = b; a.Foo(); //// and A a; B b; a = b; b.Foo(); The reason I ask is I'm wondering if making the type (and value) of an assignment expression the right hand side rather than the left hand side would silently break code. It would be handy for cases like this because it avoids the need for a temp variable: class C { } class D : C { int i();} D newD(); C c; void main() { (c = newD()).i(); }
May 21 2009
BCS wrote:Are there any cases where the following cases both compile but are not identical? A a; B b; a = b; a.Foo(); //// and A a; B b; a = b; b.Foo();struct A { int i; void Foo() { i = 42; } } alias A B; The first case will set a.i to 42, the second will set b.i. And with opAssign + different struct types they'd be calling two completely different Foo()s. Then there's array types + global function Foo(ref A), union types (similar to struct types), class types + static Foo()s (different ones for A and B), ...
May 21 2009
Reply to Frits,BCS wrote:I wasn't looking for side effect cases but I guess that is correct.Are there any cases where the following cases both compile but are not identical? A a; B b; a = b; a.Foo(); //// and A a; B b; a = b; b.Foo();struct A { int i; void Foo() { i = 42; } } alias A B; The first case will set a.i to 42, the second will set b.i.And with opAssign + different struct types they'd be calling two completely different Foo()s.Oh, forgot opAssign (darn)Then there's array types + global function Foo(ref A), union types (similar to struct types), class types + static Foo()s (different ones for A and B), ...ok looks like to much of a mess to make it work
May 21 2009