IFTI, value types, and top-level const

[Diggory]

On Sunday, 9 June 2013 at 12:19:13 UTC, Peter Alexander wrote:
> 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.

Yeah, as long as it still prefers to match "const" during 
overload resolution then it's always possible to provide a const 
version when needed:

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

const int a = 1;
foo(a);

Clearly T should match "int" rather than "const(int)", and then 
the second overload called.