IFTI, value types, and top-level const

Peter Alexander peter.alexander.au at gmail.com
Sun Jun 9 05:19:12 PDT 2013


On Sunday, 9 June 2013 at 10:49:17 UTC, Jonathan M Davis wrote:
> 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.

A full copy is only required if you go from const->mutable, but 
that's completely expected and unavoidable. Going from 
const->const or mutable->mutable will preserve the move 
opportunity.

It's completely a non-issue as far as I'm concerned: if you want 
a mutable value and you're given a const value then you *must* 
make a deep copy. This is true in current D.

The difference comes in with how we handle IFTI.

When I see this:

void foo(T)(T x) {}

I read this as explicitly requesting a mutable T, and if you call 
it with a const(T) then yes you will need a copy (it's 
unavoidable).

I would suggest that if you do NOT need a mutable T, then you 
should specifically ask for const:

void foo(T)(const T x) {}

That way, you get the move no matter what.



More information about the Digitalmars-d mailing list