Oops, exception specifications don't work as well as default template arguments in this context. Anyway, it's up to you, the implementer :) .

I believe there are no guarantees that any C++ library member function doesn't have extra undocumented/hidden parameters, so long as existing call sites work. This would make the behavior your observing is within the rights of the implementation.

No, the behavior is not equivalent to the spec under the as-if rule.

The standard says:

"An implementation shall not declare a global or non-member function signature with additional default arguments."

That doesn't appear to cover your example of inheriting the constructor.

Default arguments are allowed as long as they don't break something else. They are allowed as an implementation detail, such that the library may be used "as if" they did not exist.

Are you seriously saying that because default arguments are allowed, inheritance from standard classes is not?

Default arguments are allowed as long as they don't break something else.

The actual rule is more permissive than that. [member.functions] (17.6.5.5)/2 says:

"An implementation may declare additional non-virtual member function signatures within a class:
-- by adding arguments with default values to a member function signature
-- [...]"

See also http://cplusplus.github.io/LWG/lwg-active.html#2259, which fixes some wording issues in this paragraph, but doesn't fundamentally change the rule in this case.

But I think this is largely academic: the original code seems reasonable, and I think we should accept it. My preferred fix is to fix the specification for inheriting constructors, but failing that, changing libc++ as a QoI issue seems reasonable to me.

Converting constructors test case.

Sorry, Wrong bug :(

Ok, so I agree that this is a problem and think we should move the SFINAE to the template parameters. Moving it to the template parameters does work, but it won't make std::function accept this code. My reading of the standard suggests that this code should be accepted since it says nothing about disabling the template constructor when T == std::function. I think this was probably omitted since 12.8.6 disables that constructor in the case where T == std::function anyway.

HOWEVER, this example is one hell of a corner case and I'm worried about allowing this. I just want to reiterate what David's example code should do because it took me a long time to figure out.

12.8.6 says:
A declaration of a constructor for a class X is ill-formed if its first parameter is of type (optionally cv-qualified)
X and either there are no other parameters or else all other parameters have default arguments. A member
function template is never instantiated to produce such a constructor signature. [ Example:
struct S {
template S(T);
S();
};
S g;
void h() {
S a(g); // does not instantiate the member template to produce S::S(S);
// uses the implicitly declared copy constructor
}
—end example ]

Huh, I thought a change was needed to accept the following code based on 12.9/1.2 as discussed. But this case seems to be accepted without any changes:

#include

struct A : std::function<int()> {
using function::function;
};

int main() {
std::function<long()> f(nullptr);
A a(f);
}

Not sure why though... It seems like the default argument should be omitted.

Perhaps because passing an lvalue causes a reference type to be deduced, which might jiggle the SFINAE differently. The SFINAE might contain unnecessary logic to prevent instantiating a copy constructor, which went unnoticed and untested until now. (A constructor template will usually not generate a copy constructor, because the implicit one is always more specialized. I seem to recall there's a strict rule that forbids it from ever happening, but that shouldn't be relevant here.)

On the other hand, I realize now that I've been abusing inheriting constructors in this case, so thank you. I'll file a core language defect report, and fix my own project.

As of now, I plan to propose that copy and move constructors should be inherited as deleted rather than ignored. (Of course, a user-defined alias would override this.)

By the way, I've written a std::function compatible library https://github.com/potswa/cxx_function which does support inheriting constructors (and uses them internally). An issue did arise which fits the description of the previous comment and the CWG DR. The fix was a deleted overload:

https://github.com/potswa/cxx_function/blob/7a54cfbde6bb5717f1b8ef8c6083a3a6499f5513/cxx_function.hpp#L791

This has been fixed in 2 different ways:

1. I implemented a fix in libc++ even though it's no longer needed (see below)

2. Inheriting constructors were fixed in the standard and this fix has been implemented in Clang as of 3.9.