So once upon a time we had P1317, which intended to make std::apply SFINAE-friendly. Which then got feedback to also make std::make_from_tuple SFINAE-friendly at the same time. We should... just do that.

Thanks for your information! I found this issue while trying to write a test for LWG3528, and I didn't know P1317 existed before, but it seems P1317 hasn't been updated in a few years. Since this improvement is already implemented in libc++ and MSVC STL as an enhancement(many thanks for PR reviewers), I would like to standardize it as a short proposal paper.

If the effects are "Equivalent to" calling a constrained function, don't the constraints apply to std::make_from_tuple already?

Thanks for your reply! Somehow I forgot to attach a CompilerExplorer link in the original mail to make it more clear. https://godbolt.org/z/x8T1Kqv6c , we avoid hard errors in the top three windows by adding simple constraints on make_from_tuple.

This is somehow unclear when the constraints are not literally specified with "Constraints:" in the standard wording ([structure.specifications]/4). At least "Equivalent to" doesn't propagate every substitution failure in immediate context. E.g. it's noted in https://github.com/cplusplus/draft/pull/6900#discussion_r1537381337 that the ill-formedness of destructor call shouldn't participate in SFINAE.

In the case of std::make_from_tuple/LWG3528, the constrains of apply-impl, the constraints were introduced via a requires-clause but not literal "Constraints". Some implementors believed the requires-clause should be treated same as Constraints, but this is not explicitly stated.

Also, if it's intended to make std::make_from_tuple SFINAE-friendly, the Mandates should be turned into Constraints...

Thanks for the detailed explanation! This is my first time submitting a proposal, do I need to write a paper in PDF/HTML format first, before reviewing it later?

Best,

Yrong