Give sum_value and sum_error a noexcept specification#298
Conversation
🤖 Augment PR SummarySummary: Makes the graded-monad lifts Changes:
Technical Notes: The lifting overloads remain conservatively 🤖 Was this summary useful? React with 👍 or 👎 |
| fn::expected<int, Error> a{12}; | ||
| return fn::sum_value(a).value() == fn::sum{12}; | ||
| }()); | ||
| SUCCEED(); |
There was a problem hiding this comment.
tests/fn/expected.cpp:251: The new WHEN("constexpr")/WHEN("noexcept") sections only use static_assert plus SUCCEED(), so they don’t actually validate the behavior at runtime. Consider adding runtime CHECK/CHECK_FALSE counterparts (even if they mirror the constant expressions) to match the repo’s “runtime + constexpr twin” testing convention.
Severity: low
Other Locations
tests/fn/optional.cpp:95
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
3acb5e5 to
23c55fa
Compare
No overload had one, so a pipeline crossing them lost `noexcept` unnecessarily. The overloads whose side already is a sum return `*this` by reference and cannot throw, so they are unconditionally `noexcept`; the lifting overloads wrap one side in a sum and relocate the other, so they weigh both constructions, and the free functions propagate whatever the member says. The lifting overloads still report `noexcept(false)` even for trivial types, because `sum`'s own value constructor carries no specifier to derive from (#280) - conservatively correct, and it sharpens when that lands. The tests assert both halves. Closes #276 Assisted-by: Claude:claude-opus-4-8[1m]
They were the only monadic members not declared `constexpr`, so a constexpr pipeline could not cross the graded lift - and the free functions, though marked `constexpr` themselves, forwarded to them and were equally unusable. Assisted-by: Claude:claude-opus-4-8[1m]
683c4a1 to
3beae5a
Compare
|
augment review |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
Flip #276's tripwires: the self-returning sum_value and sum_error overloads are noexcept now, while the lifting ones stay conservatively false and are re-pinned to #280, the sum value constructor whose missing specifier they weigh. Take #298's constexpr coverage, and its free-function noexcept probes folded into the sections that already assert those functions' return types - main states the rest in separate blocks, which those sections already cover, per value category and in place. Assisted-by: Claude:claude-opus-4-8[1m]



Both
sum_value/sum_errorgaps: the missingnoexceptspecification, and the missingconstexpr.Give
sum_valueandsum_erroranoexceptspecificationNo overload had one, so a pipeline crossing them lost
noexceptunnecessarily. The overloads whose side already is a sum return*thisby reference and cannot throw, so they are unconditionallynoexcept; the lifting overloads wrap one side in a sum and relocate the other, so they weigh both constructions, and the free functions propagate whatever the member says.The lifting overloads still report
noexcept(false)even for trivial types, becausesum's own value constructor carries no specifier to derive from (#280) - conservatively correct, and it sharpens when that lands. The tests assert both halves.Make
sum_valueandsum_errorusable in a constant expressionThey were the only monadic members not declared
constexpr, so a constexpr pipeline could not cross the graded lift - and the free functions, though markedconstexprthemselves, forwarded to them and were equally unusable.Closes #276
Stack: P4 of 13 — the release-0.1 bugfix queue, merging bottom-up into
main. Based on #297 and to be retargeted tomainonce 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 ofmain, and the aggregate branch ran the full CI matrix green (#289).