IFTI, value types, and top-level const

[Jonathan M Davis]

On Sunday, June 09, 2013 13:02:09 monarch_dodra wrote:
> On Sunday, 9 June 2013 at 10:49:17 UTC, Jonathan M Davis wrote:
> > I fully expect that copy constructors could be added, and
> > AFAIK, we're going
> > to have to at some point, because postlbit constructors cannot
> > copy const or
> > immutable objects - even to create another const or immutable
> > object. Postblit
> > constructors simply do not work with const or immutable,
> > because what they're
> > trying to do is fundamentally broken with const or immutable.
> > You must create
> > objects as const or immutable, not copy them and then alter
> > them as postblits
> > do. It's come up before, and Andrei and Walter have discussed
> > it and
> > supposedly have some sort of solution, but they've never
> > explained it
> > publicly, and AFIK, nothing has been done to fix the problem.
> > 
> > - Jonathan M Davis
> 
> I don't really see what sets apart a "copy constructor" from a
> "postblit contructor": They have a different sequence of
> operations, but it's not like the copy constructor will magically
> have the object ready for use without ever mutating anything?
> 
> So if your CC looks like this:
> struct S
> {
>      int i = 0;
>      this(typeof(this) other)
>      {
>          i = other.i; //oops! mutable operation!
>      }
> }
> 
> Back to square one, no?
> 
> Just because postblit means "copy the bits over, and then
> construct", doesn't mean the compiler has to place the actual
> bits in the immutable area before the object is completly
> constructed. Which is how a CC would work around the problem,
> unless I'm mistaken.
> 
> postblit should just be able to modify its own members, as if
> they were tail const (though there might be a problem for class
> references...). The problem right now (AFAIK), is that for the
> compiler, postblit is "just" a function, but it should be more
> than that.

A copy constructor for const or immutable would be in the same boat as any 
const or immutable constructor. No portion of the object gets mutated. It's 
constructed as const or immutable, and anything else is an error. But postblit 
constructors specifically do a bitwise copy and then start mutating the newly 
constructed struct, and that violates the type system, because it would mean 
that it's mutating a const or immutable object. And whereas a const or 
immutable constructor cannot assign a member variable after that member 
variable has been read, a postblit constructor _has_ to or it can't look at 
the state of the original object to copy it, because it doesn't have access to 
the original object and therefore can only look at the current object (which 
is a bitwise copy of the original). I just don't see how you can make postblit 
constructors work with const or immutable without violating the type system.

- Jonathan M Davis