digitalmars.D.bugs - [Issue 9665] New: Structure constant members can not be initialized if have opAssign
- d-bugmail puremagic.com (52/52) Mar 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (29/29) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (11/12) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (7/11) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (7/14) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (33/40) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (9/22) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (16/19) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (14/21) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (20/20) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (10/10) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (16/20) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (8/8) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (16/28) Mar 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (16/42) Mar 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (22/40) Mar 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (17/33) Mar 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (6/6) May 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (8/9) May 07 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (10/10) Oct 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (34/34) Oct 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (7/7) Oct 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (12/12) Oct 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (13/13) Oct 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (10/10) Oct 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (15/15) Oct 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (9/9) Oct 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (10/10) Oct 14 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (10/10) Oct 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (13/13) Nov 03 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
- d-bugmail puremagic.com (9/9) Nov 03 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9665
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Summary: Structure constant members can not be initialized if have opAssign Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: maximzms gmail.com PST --- Normally constant members of a structure can be initialized in constructor. However this is not possible if they have overloading of assignment operator. This restricts usage of complex numbers from std.complex since they are structures with opAssign. ------------------- struct Foo1 // opAssign is a function { int value; void opAssign(int src) { value = src; } } struct Foo2 // opAssign is a template { int value; void opAssign()(int src) { value = src; } } struct Boo { const Foo1 f1; const Foo2 f2; this(int src) { f1 = src; // Error! f2 = src; // Error! } } void main() {} ------------------- test.d(20): Error: mutable method test.Foo1.opAssign is not callable using a const object test.d(21): Error: template test.Foo2.opAssign does not match any function template declaration. Candidates are: test.d(10): test.Foo2.opAssign()(int src) test.d(21): Error: template test.Foo2.opAssign()(int src) cannot deduce template function from argument types !()(int) ------------------- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 08 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nobody puremagic.com |andrei erdani.com This is unfixable problem, if I'm not mistaken. Currently, compiler always considers opAssign operator overloading for all field "assignment" in constructor. struct S { T field; this(...) { field = xxx; } // If T has opAssign, it is called. } But for non-mutable field, opAssign invocation is not legal, because it may break const correctness. T* p; struct T { void opAssign(int n) { ...; p = &this; } } struct S { immutable T field; this(...) { field = 1; // invoke T.opAssign (currently not allowed) /* now global p holds mutable pointer to immutable T object! */ } } I have no answer for this issue... So, assigned to Andrei. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich gmail.com 09:07:15 PST ---This is unfixable problem, if I'm not mistaken.What if opAssign is const/inout? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665It would be invoked, but you cannot do any meaningful operation in it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------This is unfixable problem, if I'm not mistaken.What if opAssign is const/inout?
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 09:16:40 PST ---I see. Is there any use for a const opAssign? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------It would be invoked, but you cannot do any meaningful operation in it.This is unfixable problem, if I'm not mistaken.What if opAssign is const/inout?
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 rswhite4 googlemail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rswhite4 googlemail.comYou can: import std.stdio; import std.c.string : memcpy; struct Foo1 // opAssign is a function { int value; void opAssign(int src) const { int* ptr = cast(int*) &this.value; *ptr = src; } } struct Boo { const Foo1 f1; this(int src) { f1 = src; // Error! } } void main() { Boo b = Boo(42); writeln(b.f1.value); // prints 42 } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------It would be invoked, but you cannot do any meaningful operation in it.This is unfixable problem, if I'm not mistaken.What if opAssign is const/inout?
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 PST ---But for non-mutable field, opAssign invocation is not legal, because it may break const correctness. T* p; struct T { void opAssign(int n) { ...; p = &this; } } struct S { immutable T field; this(...) { field = 1; // invoke T.opAssign (currently not allowed) /* now global p holds mutable pointer to immutable T object! */ } }Is there any way to break const correctness if opAssign is pure? If not, then changes should be allowed for pure opAssign (e.g. with implicit cast field to mutable). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 [snip] To enforce breaking type system by language users is not good at all. When talking about language semantics, unsafe operation like cast must not appear. Language user can break type system explicitly, but compiler must not do it.Is there any way to break const correctness if opAssign is pure?'pure' attribute does not affect constancy.If not, then changes should be allowed for pure opAssign (e.g. with implicit cast field to mutable).opAssign should modify its 'this' object for the meaningful operation, but mutable method cannot call on non-const object, even inside constructor. So this problem is unfixable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Maxim Fomin <maxim maxim-fomin.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maxim maxim-fomin.ru ---Normally constant members of a structure can be initialized in constructor. However this is not possible if they have overloading of assignment operator. This restricts usage of complex numbers from std.complex since they are structures with opAssign. <skipped>You can do: f2.value = src; which doesn't require opAssign as well as doesn't scale as structure grows. This does not work either when structure has private members. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 PST --- This is an insufficiency in D's design. I think we should approach this the same way as super() invocation and construction of qualified objects: 1. When a constructor is entered, the object is in a "raw" state. 2. While in this raw state, the object is not considered initialized so it can't be passed to functions etc. Its const/immutable members (be they by their own qualifier or propagated from the object) are also raw and can't be passed out. 3. This raw state lasts until super() has been called EXACTLY ONCE and each qualified field has been assigned to EXACTLY ONCE. 4. At that point the object has become "cooked" and all restrictions are lifted. Kenji, I recall we discussed this design in the context of const and immutable constructors, and you were favorable to it. How about we extend the same design for initializing qualified members in all contexts? We can reuse the same primitive flow analysis that's now used for super(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Andrei Alexandrescu <andrei erdani.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrei erdani.com 17:43:08 PST --- Assigned to Kenji :o). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major --- Thanks for your nice reply! I have recalled description written in TDPL.Kenji, I recall we discussed this design in the context of const and immutable constructors, and you were favorable to it. How about we extend the same design for initializing qualified members in all contexts?I think it is possible. Now I completely understood. We should need some control flow analysis that is similar to calling super() for the process of initializing object field.Assigned to Kenji :o).I have received your request! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 18:32:32 PST --- Kenji: that's exactly right. Just in case it isn't obvious, that only assignment for qualified fields while in raw state is not an opAssign call, it's a constructor call. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 ---This is an insufficiency in D's design. I think we should approach this the same way as super() invocation and construction of qualified objectsThis is close to const vs postblit problem. The problem appeared due to unthoughtful decision to allow const objects mutation during construction. But it is too late now.3. This raw state lasts until super() has been called EXACTLY ONCE and each qualified field has been assigned to EXACTLY ONCE.I am afraid such limitation would hurt programming in cases when raw object is touched more than once. By the way, what is about example in comment 1 when non-const opAssign stores mutable pointer to immutable data?4. At that point the object has become "cooked" and all restrictions are lifted. Kenji, I recall we discussed this design in the context of const and immutable constructors, and you were favorable to it. How about we extend the same design for initializing qualified members in all contexts? We can reuse the same primitive flow analysis that's now used for super().I think it would be better to have special qualifier for such situation. Anyway we implicitly have it. Problem with flow analysis is that callee may have no idea who is caller due to separate compilation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 10 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 12:33:50 PDT ---I disagree it's too late, seeing as I actually propose a solution. Also, this is probably not the best forum to air criticisms about the competence and state of mind of the language designers.This is an insufficiency in D's design. I think we should approach this the same way as super() invocation and construction of qualified objectsThis is close to const vs postblit problem. The problem appeared due to unthoughtful decision to allow const objects mutation during construction. But it is too late now.I agree it would disallow some correct code, but it's not a strong limitation to ask for exactly one initialization.3. This raw state lasts until super() has been called EXACTLY ONCE and each qualified field has been assigned to EXACTLY ONCE.I am afraid such limitation would hurt programming in cases when raw object is touched more than once.By the way, what is about example in comment 1 when non-const opAssign stores mutable pointer to immutable data?I'm not sure what you mean. What about it? This can't occur in the proposed raw/cooked design.I disagree. A new qualifier would complicate the language much more than a typechecking rule for constructors. BTW the raw/cooked design is proven - it's been already used in a number of papers and languages. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------4. At that point the object has become "cooked" and all restrictions are lifted. Kenji, I recall we discussed this design in the context of const and immutable constructors, and you were favorable to it. How about we extend the same design for initializing qualified members in all contexts? We can reuse the same primitive flow analysis that's now used for super().I think it would be better to have special qualifier for such situation. Anyway we implicitly have it. Problem with flow analysis is that callee may have no idea who is caller due to separate compilation.
Mar 10 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 ---The purpose was not to insult language designers but to point that affecting one feature may break its interaction with other features.I disagree it's too late, seeing as I actually propose a solution. Also, this is probably not the best forum to air criticisms about the competence and state of mind of the language designers.This is an insufficiency in D's design. I think we should approach this the same way as super() invocation and construction of qualified objectsThis is close to const vs postblit problem. The problem appeared due to unthoughtful decision to allow const objects mutation during construction. But it is too late now.From what I understood, the proposal is to relax(remove temporarily) constness of members during ctor invocation which allows code like below: T* p; struct T { void opAssign(int n) { ...; p = &this; } } struct S { immutable T field; this(...) { field = 1; // invoke T.opAssign (currently not allowed) /* now global p holds mutable pointer to immutable T object! */ } } Or I misunderstood completely and you really proposing to call something like super(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------By the way, what is about example in comment 1 when non-const opAssign stores mutable pointer to immutable data?I'm not sure what you mean. What about it? This can't occur in the proposed raw/cooked design.
Mar 10 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 ---From what I understood, the proposal is to relax(remove temporarily) constness of members during ctor invocation which allows code like below: T* p; struct T { void opAssign(int n) { ...; p = &this; } } struct S { immutable T field; this(...) { field = 1; // invoke T.opAssign (currently not allowed) /* now global p holds mutable pointer to immutable T object! */ } } Or I misunderstood completely and you really proposing to call something like super().In the raw/cooked design, you cannot call mutable T.opAssign from immutable field, even inside constructor. Instead, you should use whole object "assignment" for the field. struct S { immutable T field; this(...) { field = immutable(T)(...); // T's literal or constructor call // This _looks like_ "assignment" but in practice // it would be treated as initializing. So opAssign is not invoked. } } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 10 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 19:00:14 PDT --- So Kenji, did you fix this bug in trunk? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 ---So Kenji, did you fix this bug in trunk?In local I've tried to fix this, but it had broke Phobos compilation by the lack of proper postblit feature. Sorry... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 07 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |samukha voliacable.com --- *** Issue 11204 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 10 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 PDT --- I see there was a discussion in bug 9665. Kenji, if you are fixing this, please don't forget about postblit, which is a constructor and should have similar semantics. That is: struct S { disable this(); this(int x) { } static int postblit; this(this) { postblit = true; } static int assigned; void opAssign(S s) { assigned = true; } } class A { S s; this() { auto s1 = S(1); s = s1; assert(!S.assigned); assert(S.postblit); } } void main() { auto a = new A; } Copy-construction should be performed, not assignment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 10 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 PDT --- "I see there was a discussion in bug 9665." - ignore this sentence. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 10 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull, rejects-valid Blocks| |11186, 11246, 10357 --- https://github.com/D-Programming-Language/dmd/pull/2665 https://github.com/D-Programming-Language/phobos/pull/1637 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/644e11ea46ac671b4a1a34a31ef5e72a6f89a2d2 fix Issue 9665 - Structure constant members can not be initialized if have opAssign https://github.com/D-Programming-Language/phobos/commit/5f725db1141d98c67ee3515f4edb7b43692173d7 Supplemental fix for issue 9665 - Structure constant members can not be initialized if have opAssign -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Commit pushed to 2.064 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/f5606620c5f106694a6c1ec082587d8ffba1a6c7 Supplemental fix for issue 9665 - Structure constant members can not be initialized if have opAssign -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f8386c7eeb2518779e42e753507538188c1e3be5 fix Issue 9665 - Structure constant members can not be initialized if have opAssign - Change the first field assignment inside constructor to true initialization. - Disable multiple initialization of non-mutable field, if it is once initialized. https://github.com/D-Programming-Language/dmd/commit/84ee9522f470cdb90031c4a8542c32e753d1462c Issue 9665 - Structure constant members can not be initialized if have opAssign -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Commit pushed to 2.064 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/44d568a7f83a43d6bbd31cbcfcf194da39a3beb7 Issue 9665 - Structure constant members can not be initialized if have opAssign -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla digitalmars.com Resolution| |FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |acehreli yahoo.com --- *** Issue 9732 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/76bf0a581313aa6f2702f23a577f28d32a5d385f fix Issue 9665 - Structure constant members can not be initialized if have opAssign Describe about field initialization behavior. https://github.com/D-Programming-Language/dlang.org/commit/0af070ef719ef65ddd325dfb5d68b5fd987ce6aa Issue 9665 - Structure constant members can not be initialized if have opAssign -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 03 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Commit pushed to 2.064 at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/101d3a7a229b45bd97bc922f7c4df465f72d2432 Issue 9665 - Structure constant members can not be initialized if have opAssign -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 03 2013