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
d-bugmail puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=11346
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?
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