Fix ambiguous partial specialization when appending a sum to a pack#295
Merged
Conversation
`_pack_append`'s two specializations both matched a sum and neither subsumed the other, so naming `append_type<sum>` was ill-formed: gcc hard-errored even inside a requires-expression, while clang answered false. They now exclude each other, and the sum case defines no `type`, making the rejection a clean substitution failure on both compilers. Drops `_append<sum> = delete`, which `append`'s trailing return type made unreachable. Closes #282 Assisted-by: Claude:claude-opus-4-8[1m]
The tag selects the element type; it is never an element. With a type that has no default constructor the in-place overload dropped out on its `is_constructible_v` conjunct and the deduced-argument overload picked the call up, silently appending the tag itself, so `append(in_place_type<T>)` meant "construct a T" or "append the tag" depending on a property of T. The deduced-argument overloads now carry the guard `as_pack` already had, leaving the in-place overload as the only candidate for a tag. Closes #283 Assisted-by: Claude:claude-opus-4-8[1m]
This was referenced Jul 13, 2026
🤖 Augment PR SummarySummary: Fixes two constraint/overload-resolution defects in Changes:
🤖 Was this summary useful? React with 👍 or 👎 |
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Member
Author
|
augment review |
Bronek
added a commit
that referenced
this pull request
Jul 13, 2026
Take #295's corrected pack.append expectations into the restructured constraints section: it fixes #282 and #283, which this branch had pinned as GAP comments, and makes the sum negative probes portable at last. The #280 noexcept tripwires stay - that issue is still open. Assisted-by: Claude:claude-opus-4-8[1m]
Bronek
added a commit
that referenced
this pull request
Jul 13, 2026
The GAP note it replaces described an overload that no longer exists: #295 dropped `_append<sum> = delete` as unreachable, and made naming append_type<sum> a clean substitution failure on both compilers, which the note said no portable probe could ask. Assisted-by: Claude:claude-opus-4-8[1m]
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Two defects in the same
pack::appendoverload set.Fix ambiguous partial specialization when appending a
sumto apack_pack_append's two specializations both matched a sum and neither subsumed the other, so namingappend_type<sum>was ill-formed: gcc hard-errored even inside a requires-expression, while clang answered false. They now exclude each other, and the sum case defines notype, making the rejection a clean substitution failure on both compilers. Drops_append<sum> = delete, whichappend's trailing return type made unreachable.Reject
in_place_typeas a deducedpack::appendargumentThe tag selects the element type; it is never an element. With a type that has no default constructor the in-place overload dropped out on its
is_constructible_vconjunct and the deduced-argument overload picked the call up, silently appending the tag itself, soappend(in_place_type<T>)meant "construct a T" or "append the tag" depending on a property of T. The deduced-argument overloads now carry the guardas_packalready had, leaving the in-place overload as the only candidate for a tag.Closes #282
Closes #283
Stack: P1 of 13 — the release-0.1 bugfix queue, merging bottom-up into
main; this PR is the base of the stack. Every stack boundary was validated with a gcc build and the full test suite on top ofmain, and the aggregate branch ran the full CI matrix green (#289).