2012年4月10日11:22 Andrei Alexandrescu <seewebsiteforem...@erdani.org>: > On 4/9/12 9:03 PM, kenji hara wrote: >> It is a bug yet not fixed. >> http://d.puremagic.com/issues/show_bug.cgi?id=6174 > > I'll note that fixing this bug is more difficult than it might seem, > particularly when immutable members and immutable constructors come into > play. > > Some flow control is needed. At start each member variable of the object > starts in a "raw" state. The constructor code progressively assigns to > members, putting them in a "cooked" state. > > Although the syntax looks like assignment, the constructors should be > called for struct members. > > A "cooked" member cannot be assigned to again. > > No function call that takes this (including members) is allowed until > all members have become "cooked". > > If the constructor was const or immutable, the object effectively > becomes const or immutable exactly at the point all members are > "cooked". At that point in the constructor, the object or its members > can be passed to functions.
Yes, I understand that almost completely. I have TDPL book. The assignment to object field inside constructor should be only once, and it should be treated as construction instead of true assignment. My pull for fixing 6174 (https://github.com/D-Programming-Language/dmd/pull/166) doesn't implement it perfectly, but supports to judge an assignment inside constructor is really field assignment (==construction) or not. struct S { int[2] sarr; this(int n) { sarr[] = [n,n]; // My pull could detect the original sliced array is object field. // So we can detect whole this assignment is construction. } } I hope merging it in next release (as soon as possible) to progress developments. Kenji Hara