Title
When should the requirement for std::Returnable<T>, etc., apply?
Status
concepts
Section
9.3.4.6 [dcl.fct]
Submitter
Alberto Ganesh Barbati

Created on 2008-09-30.00:00:00 last changed 187 months ago

Messages

Date: 2008-09-30.00:00:00

If we write

    concept C<class T> {}

    template<C T>
    struct B {
         B f();
         virtual void g() = 0;
    };

... it seems reasonable to expect a diagnostic about B<T>::f() not because it doesn't require std::Returnable<B<T>> (which I think should not draw an error), but because g() is a pure virtual function.

Now how about this:

    template<C T>
    struct G {
         B<T> f() { return B<T>(); }
    };

Here, I'd like to see an error not because we lack the requirement std::Returnable<B<T>>, but because, when we instantiate B<T'> (as the current wording indicates we must within the definition of G<T>::f()), it turns out to be an abstract class.

Now, it could be that when we instantiate G, we get a different partial specialization of B, and that partial specialization could have a pure virtual member. So you might see an instantiation-time error. But partial specializations present dangers like this anyway.

I suggest we make the rule about Returnable<T> apply only in the case where T is not an instantiated archetype. The rationale is that with an instantiated archetype, it's possible to see at template definition time whether the type is abstract, whereas with a non-instantiated archetype, the only known attributes come from requirements.

I suspect we need similar changes for the declarator section. E.g., for a class template A, we shouldn't need to explicitly require VariableType<A<T>> if we want to declare a variable of type A<T>. Instead, we just instantiate A<T'> (as would be naturally required at the point of definition of a variable of type A<T'>), and issue errors when appropriate like we do with ordinary classes today.

History
Date User Action Args
2009-08-03 00:00:00adminsetstatus: open -> concepts
2008-09-30 00:00:00admincreate