IFTI, value types, and top-level const

Jonathan M Davis jmdavisProg at gmx.com
Sun Jun 9 15:56:19 PDT 2013


On Sunday, June 09, 2013 16:36:45 Timon Gehr wrote:
> On 06/09/2013 04:31 PM, Diggory wrote:
> > 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.

It's clearly as in that's the way that he thinks that it should clearly work, 
not as in that's how it's actually supposed to work. IFTI itself _never_ 
strips constness. The only place where anything close to that happens is with 
arrays, and what happens there is that IFTI takes the type of the _slice_ of 
the array, which is tail-const, so that layer of constness is effectively 
stripped, but IFTI doesn't do it directly. If the slice had been const like 
the original, then IFTI would have inferred the type as const.

It would be a definite design change to make it so that IFTI stripped 
constness. Whether that change should be made is debatable and most definitely 
_not_ clear. Maybe it should; maybe it shouldn't. The side effects of such a 
change would have to be examined in great detail.

- Jonathan M Davis


More information about the Digitalmars-d mailing list