+4  A: 

SFINAE is used only when creating a candidate set for a function overload resolution. In your first example, you are calling the overloaded f() function, and the first one is excluded thanks to SFINAE.

In your second example, when instantiate hasXZY, all its members must be well defined, and the substitution of the template parameter must not fail. It does for int::XYZ.

Members will not be excluded from the class because of a substitution failure.

Thomas
Do you have an example in mind where a class or template instanciation would compile with a member that is not well defined?
Thomas
@Armen Tsirunyan: Isn't that the answer to your question? The declaration must be well formed which is not the case for hasXZY<int>, since int::XYZ is not a type. It's not a matter of overload resolution (which can be easily checked by removing the enum from the class in which case it will still fail to compile)
Grizzly
@Grizzly: OK, you're right. I'll edit and qlarify my question.
Armen Tsirunyan
The members are instantiated if they are used, but in order to determine if a member is being used, its definition must be well-formed, otherwise how could it participate in overload resolution?
Thomas
@Thomas: Only those members whose definitions are well-formed could participate in the overload resolution. I am wondering if there is a problem with that I am overseeing
Armen Tsirunyan
+3  A: 

I'm not a C++ language lawyer, but I'll have a go at this.

In your second example, the member functions must be well-defined because they are no longer template functions once hasXZY is instantiated for int. To convince yourself of this, do the substitution for T "by hand":

struct hasXYZ
{
    typedef int                   T;
    typedef char                  no;
    typedef struct { char x[2]; } yes;

    static yes f(T::XYZ*);
    static no  f(...);
    enum {value = sizeof(f(0))==sizeof(yes)};
};

int main()
{
    std::cout << hasXYZ::value << "\n";
}

and observe that this fails to compile, with the same compiler error as before (in GCC, at least):

foo.cc:9: error: ‘T’ is not a class or namespace

By contrast, the first example compiles and behaves as expected after manual instantiation; the f members are still templated on U.

larsmans
Yeah, but why does the compiler need the declaration of a member function to be well-formed? If a member were called/used it could just try to substitute the actual template parameter. And if the substition failed for all candidates, report an error, just like in the case of SFINAE. The question is why not?
Armen Tsirunyan
*There is no* template parameter in the code I posted. Templates have been expanded, so `f` is not "instantiated upon use", it is assumed to be defined somewhere. If it's not well-formed, it can't be defined either. During template expansion, the compiler had some liberty, but now it needs to be sure it is compiling valid code, lest the linking phase fail.
larsmans
@Armen: You'd just have a method in a class that couldn't possibly be called for this specialization, and they chose to make it an error. - SFINAE only applies to templates. If the member function is a template itself, there is a possibility that the method will be callable for at least some U.
UncleBens
+2  A: 

Edit: My question is: why should the member function declararions be all well-formed? Since the compiler instantiates the methods only upon their usage, why does it need correct declaration. Consider the above example2 as a possible use-case of this feature.

When implicitly instantiating a class template specialization, the compiler has to inspect the complete declarator of that member because it needs to know basic information about the declaration. Such can contribute to the size of the class template specialization.

If inspecting the declaration part will find out it's declaring a data-member, the sizeof value of the class will possibly yield a different value. If you would have declared a function pointer instead, this would be the case

yes (*f)(typename T::XYZ*);

The C++ language is defined in such a way that the type of a declaration is known only once the whole declaration is parsed.

You can argue that you put static there, and thus in this case this is not needed to compute its size. But it is needed for name-lookup to know what a name hasXZY<T>::f refers to and that there was declared a name f at all. The compiler will not instantiate the definition of hasXYZ::f, but it will only instantiate the non-definition part of the declaration, to gets its type and adding its name to the class type for name lookup purposes. I believe supporting delayed-instantiation for declaration of names in particular cases where it would possibly work would complicate implementation of C++ compilers and the C++ spec even more, for no comparable benefit.

And finally, in your example where you attempt to call it, the compiler has to instantiate the declaration, because it needs to lookup the name f, and for this it needs to know whether that declaration is a function or something else. So I really even theoretically can't see a way your example could work without instantiating the declaration. Note that in any case, these will not instantiate a definition of the function.

Johannes Schaub - litb