pack: `append(in_place_type<T>)` silently appends the tag as an element when T is not default-constructible

[Bronek]

pack::append(std::in_place_type<T>) means two completely different things depending on a property
of T — and the difference is silent.

• If T is default-constructible, the in-place overload (pack.hpp:48) wins and appends a
  default-constructed T. This is the intent, and tests/fn/pack.cpp's WHEN("default constructor") covers it.
• If T is not default-constructible, that overload's is_constructible_v<T, decltype(args)...>
  conjunct fails with an empty pack, so it drops out — and the deduced-argument overload
  (pack.hpp:108) picks the call up instead, appending the in_place_type_t<T> tag itself as a
  pack element.

The deduced-argument append(Arg &&arg) overloads have no guard excluding the tag type. as_pack
does have one (pack.hpp:321: requires(not some_in_place_type<T>)) — the some_in_place_type
concept exists for exactly this — but append never got it.

Verified

g++ 16.1.1 and clang 22.1.6, C++20 — both accept all of this:

struct NoDefault final { int v; explicit NoDefault(int i) noexcept : v(i) {} };
struct HasDefault final { int v = 30; };

// intended: the in_place overload constructs the element
using Good = decltype(std::declval<fn::pack<int> &>().append(std::in_place_type<HasDefault>));
static_assert(std::same_as<Good, fn::pack<int, HasDefault>>);

// footgun: the tag is appended AS AN ELEMENT
using Bad = decltype(std::declval<fn::pack<int> &>().append(std::in_place_type<NoDefault>));
static_assert(std::same_as<Bad, fn::pack<int, std::in_place_type_t<NoDefault> const &>>);

It is not merely well-formed in an unevaluated context — the pack is really built, and the tag is
passed through to the callback:

static_assert([] {
  fn::pack<int> p{7};
  auto q = p.append(std::in_place_type<NoDefault>);
  return q.size == 2 && q.invoke([](int i, auto &&tag) {
    return i == 7 && std::same_as<std::remove_cvref_t<decltype(tag)>, std::in_place_type_t<NoDefault>>;
  });
}());

So a user who writes p.append(std::in_place_type<T>) intending to append a default-constructed T,
against a T that has no default constructor, gets no diagnostic at all — just a pack with a tag
where the value should be, and a confusing error much later (or none).

Fix

Mirror as_pack's guard on the four deduced-argument append overloads (pack.hpp:108/122/136/150):

template <typename Arg>
  requires(not some_in_place_type<::std::remove_cvref_t<Arg>>)
[[nodiscard]] constexpr auto append(Arg &&arg) & noexcept -> append_type<Arg>

The in-place overload is then the only candidate for a tag argument, and a non-default-constructible
T produces a clean "no viable overload" error instead of silently changing meaning.

Found while adding requires-clause coverage to tests/fn/pack.cpp (#85). Related: #282 (also
append, also decided outside the requires-clause).

[Bronek]

Fixed on bronek/bugfixes-for-release-1.0. One adjacent defect in the same overload set, found while fixing this and fixed with it:

append constrained on is_constructible_v while _append brace-initializes. So an aggregate element could not be appended element-wise, although sum constructs exactly that (see #284), and a narrowing argument list was admitted for the body to reject:

static_assert(not std::is_constructible_v<std::array<int, 3>, int, int, int>); // no brace elision in parens init
static_assert(requires { std::array<int, 3>{1, 2, 3}; });                      // what _append actually does

fn::sum<std::array<int, 3>>{std::in_place_type<std::array<int, 3>>, 1, 2, 3};  // supported
fn::pack<int>{7}.append(std::in_place_type<std::array<int, 3>>, 1, 2, 3);      // was: not viable

pack.hpp:49/64/79/94 and pack_impl.hpp:89 now use the same constraint as sum (fn::detail::_initializable), which asks about the initialization the body performs. Verified on g++ 16.1.1 and clang 22.1.6.

Portability note that shaped the constraint: T{args...} is not a portable question to ask about a reference T — g++ rejects it (no prvalue of reference type), clang++ accepts it — so that leg of the constraint asks about the binding (is_constructible_v) instead. This matters because reference pack elements are supported and tested (T::append_type<B &>).

That in turn surfaced a separate, pre-existing bug in the same body, which I am reporting on its own rather than folding in here — _append's T{FWD(args)...} does not compile on g++ when T is a reference and the body is actually instantiated; today's tests only take decltype(...) of such a call, so it has never been exercised.

Assisted-by: Claude:claude-opus-4-8[1m]