[cxx-abi-dev] Proposed ABI changes for new C++0x SFINAE rules

[David Vandevoorde]

On Sep 15, 2010, at 1:20 PM, Jason Merrill wrote:

> On 06/30/2010 11:33 AM, David Vandevoorde wrote:
>> - We're introducing a new definition: "instantiation-dependent".  When encoding a signature that contains a non-dependent expression like "sizeof(int)", existing practice it to just replace that by the resulting value, or in some cases, by the encoding for a literal representing that value.  For example:
>> 
>> 	template<class T, int N>  struct S {};
>> 	template<class T>  void f(S<T, sizeof(int)>);
>> 	  // "sizeof(int)" is encoded as "Li4E" on typical platforms;
>> 	  // i.e., as if we'd written "4" instead.
>> 
>> Similarly, something like "decltype(int)" is just encoded as the known underlying type.
>> 
>> However, there are non-dependent expressions and types that can still fail instantiation.  With the new SFINAE rules, several template declarations differing only in such expressions can be written such that their encodings don't collide.  So reducing a sizeof/decltype that is applied to such an expression to a literal isn't workable.  Here is an example of the idea:
>> 
>> 	template<class T>  auto f(T *p)->decltype(sizeof(sizeof(T)));
>> 
>> "sizeof(sizeof(T))" is neither type-dependent nor value-dependent, but if T is e.g. a function type, that declaration will be "SFINAEed out".
>> 
>> So an "instantiation-dependent" expression or type is one that is either type-dependent or value-dependent, or one that contains a type-dependent or value-dependent sub-expression.  decltype, sizeof, and alignof must be fully encoded if (and only if) their operand is "instantiation-dependent"; otherwise, the resulting type/value is encoded instead.
> 
> As I was saying in Rapperswil, I believe this is the same as the 14.5.6.1 notion of "expression involving template parameters".  Do you agree?


Yes, I think so (for expressions).


> The question is, do we need to adjust the definitions of dependent types/expressions in 14.6.2?  I suppose not; the primary purpose of the notion of dependent names/types/expressions is name lookup, and this doesn't need to affect that.

That's also my conclusion.


>  I guess that means the compiler needs to track both the full expression and its constant value, and so on through array types and template-ids that use them.

I'm not sure I understand this point.  Mostly (for this purpose), the compiler has to track the "instantiation-dependent" property for the expression.

	Daveed