Skip to content

Answer convertible_to_unexpected for void instead of hard-erroring#306

Open
Bronek wants to merge 3 commits into
bronek/P11/initialization_questionsfrom
bronek/P12/void_convertible_concepts
Open

Answer convertible_to_unexpected for void instead of hard-erroring#306
Bronek wants to merge 3 commits into
bronek/P11/initialization_questionsfrom
bronek/P12/void_convertible_concepts

Conversation

@Bronek

@Bronek Bronek commented Jul 13, 2026

Copy link
Copy Markdown
Member

The same void conjunct for all three convertibility concepts whose named type is ill-formed to instantiate for void.

Answer convertible_to_unexpected for void instead of hard-erroring

The mandate of unexpected<void> fires during instantiation, outside any immediate context - so the concept must not name it for void, which has no unexpected to convert to anyway.

Extend the void answer to convertible_to_optional and convertible_to_choice

The same class-body mandates that the convertible_to_unexpected conjunct keeps out of reach - optional<void> and choice<void> are ill-formed to instantiate, so each concept says no to void instead of asking.

Closes #290
Closes #293


Stack: P12 of 13 — the release-0.1 bugfix queue, merging bottom-up into main. Based on #305 and to be retargeted to main once it merges; the diff shows only this PR's commits. Every stack boundary was validated with a gcc build and the full test suite on top of main, and the aggregate branch ran the full CI matrix green (#289).

@augmentcode

augmentcode Bot commented Jul 13, 2026

Copy link
Copy Markdown
🤖 Augment PR Summary

Summary: This PR makes the convertibility concepts handle void safely, returning false instead of hard-erroring during template instantiation.

Changes:

  • Adds std::is_void_v<T> short-circuits to convertible_to_unexpected, convertible_to_optional, and convertible_to_choice to avoid naming ill-formed *<void> instantiations.
  • Updates convertible_to_expected to use the same is_void_v-based void handling (including cv-void).
  • Adds compile-time tests covering void and cv-qualified void for the concepts, plus transform/transform_error invocability checks for void-returning callbacks.

Technical Notes: The new guards prevent class-body mandates (e.g. unexpected<void>/optional<void>/choice<void>) from firing outside immediate context.

🤖 Was this summary useful? React with 👍 or 👎

@augmentcode augmentcode Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review completed. 1 suggestion posted.

Fix All in Augment

Comment augment review to trigger a new review at any time.

Comment thread include/fn/concepts.hpp Outdated
@Bronek

Bronek commented Jul 13, 2026

Copy link
Copy Markdown
Member Author

augment review

@augmentcode augmentcode Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review completed. 1 suggestion posted.

Fix All in Augment

Comment augment review to trigger a new review at any time.

Comment thread tests/fn/concepts.cpp
@Bronek

Bronek commented Jul 13, 2026

Copy link
Copy Markdown
Member Author

augment review

@augmentcode augmentcode Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review completed. No suggestions at this time.

Comment augment review to trigger a new review at any time.

Bronek added 3 commits July 13, 2026 17:41
The mandate of `unexpected<void>` fires during instantiation, outside any
immediate context - so the concept must not name it for void, which has no
unexpected to convert to anyway.

Closes #290

Assisted-by: Claude:claude-fable-5
…to_choice`

The same class-body mandates that the `convertible_to_unexpected` conjunct keeps
out of reach - `optional<void>` and `choice<void>` are ill-formed to instantiate,
so each concept says no to void instead of asking.

Closes #293

Assisted-by: Claude:claude-fable-5
`remove_cvref_t` folds cv-qualified void back to plain `void` inside each
concept's naming, but the guard asked `same_as<T, void>`, which `void const`
passes - reaching the same ill-formed instantiations the conjunct exists to
avoid. The guard now asks `is_void_v`. `convertible_to_expected`'s arms answer
through the same trait: a cv-qualified void is a void, on both sides of the
question. Not reachable through deduction - a call expression never has
cv-qualified void type ([expr.type]/2) - but the concepts are public surface,
and an explicit spelling must get an answer.

Assisted-by: Claude:claude-fable-5
@Bronek Bronek force-pushed the bronek/P12/void_convertible_concepts branch from 75d05c5 to 863917f Compare July 13, 2026 16:44
@Bronek Bronek force-pushed the bronek/P11/initialization_questions branch from 2f50521 to 68e5e78 Compare July 13, 2026 16:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant