>
> 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