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

[d-bugmail at puremagic.com]

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



--- Comment #14 from Andrei Alexandrescu <andrei at 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: -------