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!"

2012$BG/(B4$B7n(B10$BF|(B10: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

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

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

2012$BG/(B4$B7n(B10$BF|(B11: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

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

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

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