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