[Issue 9665] Structure constant members can not be initialized if have opAssign

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Mar 10 13:16:17 PDT 2013


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



--- Comment #15 from Maxim Fomin <maxim at 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: -------


More information about the Digitalmars-d-bugs mailing list