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
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 09, 2012 at 09:42:25PM +0200, bearophile wrote:

 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.


[...]

I just checked out tag v2.054 of dmd from git, and the same error
happens. I guess it's a bug that nobody ran into before?


T

-- 
Music critic: "That's an imitation fugue!"
Apr 09 2012
prev sibling next sibling parent reply kenji hara <k.hara.pg gmail.com> writes:
2012年4月10日10:53 H. S. Teoh <hsteoh quickfur.ath.cx>:

 On Mon, Apr 09, 2012 at 09:42:25PM +0200, bearophile wrote:

 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.


 [...]

 I just checked out tag v2.054 of dmd from git, and the same error
 happens. I guess it's a bug that nobody ran into before?


It is a bug yet not fixed.
http://d.puremagic.com/issues/show_bug.cgi?id=6174

Kenji Hara
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
next sibling parent kenji hara <k.hara.pg gmail.com> writes:
2012年4月10日11:22 Andrei Alexandrescu
<SeeWebsiteForEmail 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
Apr 09 2012
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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

Bye,
bearophile
Apr 10 2012
parent reply 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
parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 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.


So maybe it's possible to re-use the same compiler logic 
(routines) to support built-in non-nullables (but non-nullables 
need some more logic, their management is more complex).

Bye,
bearophile
Apr 10 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 09, 2012 at 06:53:32PM -0700, H. S. Teoh wrote:

 On Mon, Apr 09, 2012 at 09:42:25PM +0200, bearophile wrote:

 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.


 [...]
 
 I just checked out tag v2.054 of dmd from git, and the same error
 happens. I guess it's a bug that nobody ran into before?


[...]

Opened new bug:

	http://d.puremagic.com/issues/show_bug.cgi?id=7882


T

-- 
"I speak better English than this villain Bush" -- Mohammed Saeed al-Sahaf,
Iraqi Minister of Information
Apr 09 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