http://d.puremagic.com/issues/show_bug.cgi?id=9665
--- Comment #15 from Maxim Fomin <ma...@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: -------