IFTI, value types, and top-level const

Timon Gehr timon.gehr at gmx.ch
Sun Jun 9 07:36:45 PDT 2013


On 06/09/2013 04:31 PM, Diggory wrote:
> 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.

Then clearly DMD is buggy.



More information about the Digitalmars-d mailing list