Out of curiosity, could you give an example for which this is_constructible is false?

#include <new>
#include <type_traits>

struct S {
  S() = default;
  S(const S&) = delete;
  S(S&&) = delete;
};

S deref() { return S{}; }
S s{};

void emplace_deref() {
  s.~S();
  new (&s) S(deref());
}

static_assert(!std::is_constructible_v<S, S>);

https://godbolt.org/z/GbsxT8P34

Thanks! Should we maybe augment the note to say "... is_constructible can be false, but the above declaration of t can still be valid."? Or "... the above declaration can be valid even if is_constructible is false"?

Or maybe: "If *i is a prvalue, there is no requirement that it is copyable (dcl.init.general)."

Maybe even, "if *i is a prvalue, i can be passed to emplace_deref without a requirement that *i is copyable (dcl.init.general)"?

Repeating "emplace_deref doesn't seem to add anything.

Editorial meeting 2021-07-16: Go with Jens' suggestion.

@timsong-cpp , please update your pull request accordingly.

I used "movable" instead since emplace(*i) would be a move rather than a copy.

@tkoeppe , this seems ready to merge now.
Make sure to squash the commits.

@tkoeppe The commit message on 1305740 is incorrect:

The normatively expressed requirement in terms of an invented initialization of a variable was prone to confusion, since such a declaration would indeed require *i to be copyable/movable, whereas the actual use of emplace-deref does not
cause any intermediate materializations of prvalues.

That invented initialization does not require *i to be copyable or movable in this case. That's exactly why it is specified this way and not with is_constructible_v or constructible_from, and the whole reason for the note's existence (and why it is a note rather than normative wording).

In the future, I would appreciate an opportunity to comment on this kind of commit messages that are going to be attributed to me before they end up in main, instead of discovering them afterwards.

@tkoeppe, this looks like the time for a force-push of master.

@timsong-cpp Sorry about that! You're right -- could you please provide a new message (that explains the clarified subtlety), and I'll update that?

How about:

A new note explains that emplace-deref requires implementations to avoid
materialization of the result of *i before the initialization. This is implied by the
normatively expressed requirement in terms of an invented initialization of a
variable, but is easily overlooked.

Thank you, I updated that!