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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------