IFTI, value types, and top-level const

Jonathan M Davis jmdavisProg at gmx.com
Sun Jun 9 03:48:58 PDT 2013


On Sunday, June 09, 2013 12:33:39 Peter Alexander wrote:
> It looks like the core issue here is that it's simply not
> possible to create a mutable copy of a const object with
> indirection:

Part of my point here (that you seem to have missed) is that there is a cost 
to making it so that const is stripped from the type even if you can do so. It 
_forces_ a copy if the value being passed in isn't mutable, whereas if the 
constness were the same, then the value being passed in could potentially be 
moved rather than copied. As such, I don't know if we even want to strip the 
constness even if we can.

> The question is, can a copy constructor be introduced into the
> language without breaking lots of code, and preserving D's
> approach to move operations, i.e. not requiring explicit C++
> style rvalue references. I'm not sure.

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.

The other big problem which is related is how to deal with tail-const and 
ranges. It's currently very difficult right now (if it's even possible), which 
makes it so that you should pretty much never mix const and ranges. I know 
that this is one of Steven Schveighoffer's pet peeves, and he's working on some 
sort of proposal to fix it, but he hasn't finished it yet.

Copying const or immutable objects in general tends to be a bit iffy unless 
they're value types.

- Jonathan M Davis


More information about the Digitalmars-d mailing list