digitalmars.D.bugs - [Issue 11346] New: [2.064 beta] field initializing not allowed in loops or after labels
- d-bugmail puremagic.com (35/35) Oct 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
- d-bugmail puremagic.com (15/38) Oct 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
- d-bugmail puremagic.com (8/8) Oct 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
- d-bugmail puremagic.com (16/19) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
- d-bugmail puremagic.com (8/8) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
- d-bugmail puremagic.com (9/9) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
- d-bugmail puremagic.com (26/26) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
- d-bugmail puremagic.com (7/10) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
- d-bugmail puremagic.com (41/42) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
- d-bugmail puremagic.com (7/7) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
- d-bugmail puremagic.com (12/14) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11346
http://d.puremagic.com/issues/show_bug.cgi?id=11346 Summary: [2.064 beta] field initializing not allowed in loops or after labels Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: regression Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: rswhite4 googlemail.com Code: ---- import std.stdio; struct Test { public: const int[] test; this(int i) { for (size_t j = 0; j < 4; ++j) { this.test ~= i + j; } } } void main() { Test t = Test(42); } ---- Error: field test initializing not allowed in loops or after labels WTF? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11346Code: ---- import std.stdio; struct Test { public: const int[] test; this(int i) { for (size_t j = 0; j < 4; ++j) { this.test ~= i + j; } } } void main() { Test t = Test(42); } ---- Error: field test initializing not allowed in loops or after labels WTF?It's intended behavior change introduced by fixing bug 9665. Possible code fix is: this(int i) { int[] tmp; for (size_t j = 0; j < 4; ++j) { tmp ~= i + j; } this.test = tmp; // initialize non-mutable field only once } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11346 That is so non intuitive. A good example how you can make simple code more complicated. I will wait for the threads in D.learn or possible bug reports for that... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11346That is so non intuitive. A good example how you can make simple code more complicated. I will wait for the threads in D.learn or possible bug reports for that...If multiple initialization for non-mutable field is allowed, it could break type system. For example: struct S { const int[] arr; this(immutable int[] a) { arr = a; // First initialization arr[0] = 1; // Second initialization - modify immutable data! } } Therefore, it's necessary limitation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11346 So it was a "bug" in 2.063.2 and will never change? It's a real _ugly _ restriction and I'm sure that many newbies don't understand that. But thanks for explanation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11346 BTW: Your example was an index assignment. Such things could be detected and therefore distinguished of "normal" assignments. Multiple assignments (as I showed in my two bug reports) for an array or an assocaitve array should be possible in the CTor. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11346 To describe my viewpoint somewhat closer: ---- if (Primitive.Target.Vertex & trg) this._targetIds[Primitive.Target.Vertex] = ids++; [1] if (Primitive.Target.Color & trg) this._targetIds[Primitive.Target.Color] = ids++; [2] if (Primitive.Target.TexCoords & trg) this._targetIds[Primitive.Target.TexCoords] = ids++; [2] ---- [1] is allowed because the compiler things, that is the first assignment for _targetIds. But that is _no_ real assignment. A real assigment would be something like that: this._targetIds = ...; It is an index assignment, so the AA is probably not fully initialized. [2] and [3] are rejected, because the compiler thinks, that this are multiple assignments. But that is plain worng. That are also index assignments to initialize my AA. Same thing for normal arrays. A assignment would be arr = [1, 2, 3]; But the operator ~= is a concatenation to initialize my array. IMO we should distinguish this. That would retain your type safety and get rid of the annoying limitation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11346So it was a "bug" in 2.063.2 and will never change? It's a real _ugly _ restriction and I'm sure that many newbies don't understand that. But thanks for explanation.Yes. Unfortunately that was a long-standing hole in the type system. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11346To describe my viewpoint somewhat closer:[snip] Unfortunately, AA indexing access and array concatenation also have the possibility of type system breaking. struct S { immutable int[] arr; this(immutable int[] a) { arr = a; assert(arr.capacity > 0); // emulate `arr ~= 10;` (* cast(int[]*) &arr) ~= 10; } } void main() { immutable int[] arr = [1,2,3]; immutable int[] a = arr[0..2]; assumeSafeAppend(a); assert(a.capacity > 0); auto s = S(a); import std.stdio; writeln(arr); // prints [1,2,10] } It's arbitrary example, but under the system code, concatenation may break type system without explicit casting. The AA case is more easy. If you access the AA by the same key twice, you will mutate once initialized non-mutable data. struct S { immutable int[string] aa; this(int n) { aa["str"] = n; aa["str"] = n; // multiple initialization } } Compiler cannot detect above case without extra runtime cost. Keep the rule for "initialization inside constructor" simple, I think the current behavior is enough acceptable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11346 I still hate it, but ok, that means for me: no more const for arrays and AA's. Thanks for your time. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11346 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ---I still hate it, but ok, that means for me: no more const for arrays and AA's. Thanks for your time.No problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013