[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-10-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9732 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-03-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9732 --- Comment #10 from Maxim Fomin 2013-03-18 14:58:55 PDT --- Another problem can arise from mixin usage - when you write mixin or mixin template you assume that opAssign would be called, but this assumptions breaks and there is no opportunitie

[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-03-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9732 --- Comment #9 from monarchdo...@gmail.com 2013-03-17 09:53:04 PDT --- (In reply to comment #7) > (In reply to comment #3) > > I really don't think that's a problem. If anything, the default value should > > NOT be destroyed in the constructor.

[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-03-17 Thread d-bugmail
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

[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-03-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9732 --- Comment #7 from Maxim Fomin 2013-03-17 09:21:59 PDT --- (In reply to comment #3) > I really don't think that's a problem. If anything, the default value should > NOT be destroyed in the constructor. After all, it hasn't really even been >

[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-03-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9732 --- Comment #6 from Maxim Fomin 2013-03-17 08:56:49 PDT --- (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 post

[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-03-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9732 --- Comment #5 from monarchdo...@gmail.com 2013-03-17 07:49:57 PDT --- I like this ER, because Contruction != Assignement. I see 0 reasons to call an opAssign in a constructor. It's just wrong. Being able to clearly make this distinction is very

[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-03-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9732 --- Comment #4 from monarchdo...@gmail.com 2013-03-17 07:21:15 PDT --- (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 exp

[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-03-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9732 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Com

[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-03-16 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9732 --- Comment #2 from Ali Cehreli 2013-03-16 22:25:36 PDT --- I think you are right because the .init state of a member may not be as simple as one thinks. Although OuterStruct.inner must be known at compile time, it may have a non-trivial destru

[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

2013-03-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=9732 Maxim Fomin changed: What|Removed |Added CC||ma...@maxim-fomin.ru --- Comment #1 from