IFTI, value types, and top-level const

monarch_dodra monarchdodra at gmail.com
Sun Jun 9 04:02:09 PDT 2013


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.


More information about the Digitalmars-d mailing list