Why std::is_constructible stops at immediate context?

Question

Originated from this topic. Also related to this topic.

My question is why std::is_constructible stops at the immediate context? I think users of std::is_constructible would expect it to work in full depth and give an exact answer. With this immediate context thing, you may have std::is_constructible give you a green light, only to get a hard compiler error when you actually do it. Doesn't this defeat the original goal and purpose of std::is_constructible. Now, it basically looks useless to me. I guess std::looks_constructible_at_first_sight would be a better name for the current semantics :(

Answer 1

If your constructor's signature is far more permissive than it should be, that's the issue - not is_constructible's implementation. In your original example,

template <typename... Ts, typename=decltype(base{std::declval<Ts>()...})>
aggregate_wrapper(Ts&&... xs)
    : base{std::forward<Ts>(xs)...} {/*…*/}

does the job. If is_constructible "spuriously" gives a green light, so might your constructor template spuriously be selected over other constructors, because overload resolution finds it to be the optimal match.

However, overload resolution isn't designed to give only true negatives/positives: It is designed to find the best match given appropriate arguments, or yield nothing if the arguments are sufficiently inappropriate. is_constructible may be superficial in some sense, but that's what traits are for - checking signatures, which are an entity's representation in the realms of overload resolution and SFINAE - not preventing that your function templates accept everything but only actually instantiate soundly for a small margin of arguments.
That's your responsibility, and if you meet it, you will both get proper results from is_constructible and efficient compilation. Which is definitely better than unfailing operation of is_constructible and high compilation times with multitudinous, hidden rules in calls to function templates.