View mode: basic / threaded / horizontal-split · Log in · Help
March 10, 2013
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665


Andrei Alexandrescu <andrei@erdani.com> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
                CC|                            |andrei@erdani.com


--- Comment #10 from Andrei Alexandrescu <andrei@erdani.com> 2013-03-09 17:43:08 PST ---
Assigned to Kenji :o).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 10, 2013
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665


Kenji Hara <k.hara.pg@gmail.com> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
          Severity|normal                      |major


--- Comment #11 from Kenji Hara <k.hara.pg@gmail.com> 2013-03-09 18:27:27 PST ---
(In reply to comment #9)

Thanks for your nice reply! I have recalled description written in TDPL.

> Kenji, I recall we discussed this design in the context of const and immutable
> constructors, and you were favorable to it. How about we extend the same design
> for initializing qualified members in all contexts?

I think it is possible.

Now I completely understood. We should need some control flow analysis that is
similar to calling super() for the process of initializing object field.

(In reply to comment #10)
> Assigned to Kenji :o).

I have received your request!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 10, 2013
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665



--- Comment #12 from Andrei Alexandrescu <andrei@erdani.com> 2013-03-09 18:32:32 PST ---
@Kenji: that's exactly right. Just in case it isn't obvious, that only
assignment for qualified fields while in raw state is not an opAssign call,
it's a constructor call.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 10, 2013
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665



--- Comment #13 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-03-10 01:53:08 PST ---
(In reply to comment #9)
> This is an insufficiency in D's design. I think we should approach this the
> same way as super() invocation and construction of qualified objects

This is close to const vs postblit problem. The problem appeared due to
unthoughtful decision to allow const objects mutation during construction. But
it is too late now.

> 3. This raw state lasts until super() has been called EXACTLY ONCE and each
> qualified field has been assigned to EXACTLY ONCE.

I am afraid such limitation would hurt programming in cases when raw object is
touched more than once.

By the way, what is about example in comment 1 when non-const opAssign stores
mutable pointer to immutable data?

> 4. At that point the object has become "cooked" and all restrictions are
> lifted.
> 
> Kenji, I recall we discussed this design in the context of const and immutable
> constructors, and you were favorable to it. How about we extend the same design
> for initializing qualified members in all contexts?
> 
> We can reuse the same primitive flow analysis that's now used for super().

I think it would be better to have special qualifier for such situation. Anyway
we implicitly have it. Problem with flow analysis is that callee may have no
idea who is caller due to separate compilation.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 10, 2013
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665



--- Comment #14 from Andrei Alexandrescu <andrei@erdani.com> 2013-03-10 12:33:50 PDT ---
(In reply to comment #13)
> (In reply to comment #9)
> > This is an insufficiency in D's design. I think we should approach this the
> > same way as super() invocation and construction of qualified objects
> 
> This is close to const vs postblit problem. The problem appeared due to
> unthoughtful decision to allow const objects mutation during construction. But
> it is too late now.

I disagree it's too late, seeing as I actually propose a solution. Also, this
is probably not the best forum to air criticisms about the competence and state
of mind of the language designers.

> > 3. This raw state lasts until super() has been called EXACTLY ONCE and each
> > qualified field has been assigned to EXACTLY ONCE.
> 
> I am afraid such limitation would hurt programming in cases when raw object is
> touched more than once.

I agree it would disallow some correct code, but it's not a strong limitation
to ask for exactly one initialization.

> By the way, what is about example in comment 1 when non-const opAssign stores
> mutable pointer to immutable data?

I'm not sure what you mean. What about it? This can't occur in the proposed
raw/cooked design.

> > 4. At that point the object has become "cooked" and all restrictions are
> > lifted.
> > 
> > Kenji, I recall we discussed this design in the context of const and immutable
> > constructors, and you were favorable to it. How about we extend the same design
> > for initializing qualified members in all contexts?
> > 
> > We can reuse the same primitive flow analysis that's now used for super().
> 
> I think it would be better to have special qualifier for such situation. Anyway
> we implicitly have it. Problem with flow analysis is that callee may have no
> idea who is caller due to separate compilation.

I disagree. A new qualifier would complicate the language much more than a
typechecking rule for constructors. BTW the raw/cooked design is proven - it's
been already used in a number of papers and languages.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 10, 2013
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665



--- Comment #15 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-03-10 13:16:15 PDT ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #9)
> > > This is an insufficiency in D's design. I think we should approach this the
> > > same way as super() invocation and construction of qualified objects
> > 
> > This is close to const vs postblit problem. The problem appeared due to
> > unthoughtful decision to allow const objects mutation during construction. But
> > it is too late now.
> 
> I disagree it's too late, seeing as I actually propose a solution. Also, this
> is probably not the best forum to air criticisms about the competence and state
> of mind of the language designers.

The purpose was not to insult language designers but to point that affecting
one feature may break its interaction with other features. 

> > By the way, what is about example in comment 1 when non-const opAssign stores
> > mutable pointer to immutable data?
> 
> I'm not sure what you mean. What about it? This can't occur in the proposed
> raw/cooked design.
> 

From what I understood, the proposal is to relax(remove temporarily) constness
of members during ctor invocation which allows code like below:

T* p;
struct T {
  void opAssign(int n) { ...; p = &this; }
}
struct S {
  immutable T field;
  this(...) { field = 1;  // invoke T.opAssign (currently not allowed)
     /* now global p holds mutable pointer to immutable T object! */
  }
}

Or I misunderstood completely and you really proposing to call something like
super().

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 11, 2013
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665



--- Comment #16 from Kenji Hara <k.hara.pg@gmail.com> 2013-03-10 20:40:34 PDT ---
(In reply to comment #15)
> From what I understood, the proposal is to relax(remove temporarily) constness
> of members during ctor invocation which allows code like below:
> 
> T* p;
> struct T {
>    void opAssign(int n) { ...; p = &this; }
> }
> struct S {
>    immutable T field;
>    this(...) { field = 1;  // invoke T.opAssign (currently not allowed)
>       /* now global p holds mutable pointer to immutable T object! */
>    }
> }
> 
> Or I misunderstood completely and you really proposing to call something like
> super().

In the raw/cooked design, you cannot call mutable T.opAssign from immutable
field, even inside constructor.

Instead, you should use whole object "assignment" for the field.

 struct S {
    immutable T field;
    this(...) {
       field = immutable(T)(...);  // T's literal or constructor call
       // This _looks like_ "assignment" but in practice
       // it would be treated as initializing. So opAssign is not invoked.
    }
 }

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 06, 2013
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665



--- Comment #17 from Andrei Alexandrescu <andrei@erdani.com> 2013-05-05 19:00:14 PDT ---
So Kenji, did you fix this bug in trunk?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 07, 2013
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665



--- Comment #18 from Kenji Hara <k.hara.pg@gmail.com> 2013-05-07 04:25:59 PDT ---
(In reply to comment #17)
> So Kenji, did you fix this bug in trunk?

In local I've tried to fix this, but it had broke Phobos compilation by the
lack of proper postblit feature. Sorry...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 10
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665


Kenji Hara <k.hara.pg@gmail.com> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
                CC|                            |samukha@voliacable.com


--- Comment #19 from Kenji Hara <k.hara.pg@gmail.com> 2013-10-10 05:14:26 PDT ---
*** Issue 11204 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
1 2 3 4
Top | Discussion index | About this forum | D home