www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can't assign to static array in ctor?

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
What's the reason the following code doesn't compile?

	struct S {
		const(int)[4] data;
		this(const(int)[4] d) {
			data = d;	// this is line 4
		}
	}

	void main() {
		S s;
	}

Compiler error:

	test.d(4): Error: slice this.data[] is not mutable

Shouldn't the assignment be valid in the ctor?


T

-- 
MSDOS = MicroSoft's Denial Of Service
Apr 09 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 	struct S {
 		const(int)[4] data;
 		this(const(int)[4] d) {
 			data = d;	// this is line 4
 		}
 	}

 	void main() {
 		S s;
 	}

I think this used to work (do you have an older DMD to verify it?). So maybe this is regression. Bye, bearophile
Apr 09 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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. Andrei
Apr 09 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/10/12 4:04 AM, bearophile wrote:
 Andrei Alexandrescu:

 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.

That reminds me of this approach to implement non-nullables: http://research.microsoft.com/pubs/67461/non-null.pdf

Yes, that's our source of inspiration for cooked/raw. Andrei
Apr 10 2012
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.1550.1333997204.4860.digitalmars-d puremagic.com...
 What's the reason the following code doesn't compile?

 struct S {
 const(int)[4] data;
 this(const(int)[4] d) {
 data = d; // this is line 4
 }
 }

 void main() {
 S s;
 }

 Compiler error:

 test.d(4): Error: slice this.data[] is not mutable

 Shouldn't the assignment be valid in the ctor?


 T

Static array assignments are converted to slice assignments waaay too early.
Apr 09 2012