From 09fad7543116a196e473b0303516a47f0c566a19 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andrzej=20Krzemie=C5=84ski?= Date: Tue, 3 Mar 2026 21:53:17 +0100 Subject: [PATCH 1/2] Update release notes for Boost 1.91.0 for opitonal Updated release notes for Boost 1.91.0, detailing breaking changes, enhancements, and new features in the optional and unordered libraries. --- release-notes/boost_1_91_0.adoc | 55 +++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/release-notes/boost_1_91_0.adoc b/release-notes/boost_1_91_0.adoc index 293acb0..50cf78d 100644 --- a/release-notes/boost_1_91_0.adoc +++ b/release-notes/boost_1_91_0.adoc @@ -77,6 +77,61 @@ a `boost::tuple` (and similarly for the rest of affected class templates). ** **Breaking change (`backmp11`)**: Direct access to the event pool is changed from `public` to `protected`, because manipulating it outside of the library code can lead to undefined behavior. + + +* boost_phrase:library[Optional,/libs/optional/]: +** For compilers with full C++11 support (including "unrestricted unions" and ref-qualifiers) + changed the implementation from aligned storage to union storage. This enables the gradual + `constexpr` support: + +*** In C++11, some constructors and `const`-qualified accessors become usable + in compile-time contexts (are ['core constant expressions]) for types + satisfying certain constraints. +*** In C++14 even some mutating operations become core constant expressions (those + that do not require changing the state of `optional` from not having a value to + having a value), for co-operating types. +*** In C++17 all constructors (including copy and move) become core constant expressions for co-operating types. + ++ + +This addresses issues https://github.com/boostorg/optional/issues/132[#132] and https://github.com/boostorg/optional/issues/143[#143]. + +** *Breaking change.* In the said implementation, abandoned the mechanism for customizing + `swap`. Hardly anyone knows about this mechanism and it was never documented. + +** In the said implementation, applied a couple of small changes to get closer to the interface of `std::optional`: + *** Enabled syntax `o = {}` for putting optional objects to no-value state. + *** Enabled syntax `o.value_or({})`, which uses a default-constructed `T`. + *** Construct `o = u`, where `o` is of type `optional` and `u` is of type `U` convertible to `T`, + does not create a temporary `T`. + +** In the said implementation, added a conversion from `optional&` to `optional`. This addresses https://github.com/boostorg/optional/issues/142[#142]. + +** `none_t` is now `std::equality_comparable`, which means that `none_t` and `optional` + model concept `std::equality_comparable_with` (for `std::equality_comparable` `T`), + which means that you can `std::ranges::find(rng, boost::none)` for a range of optional objects. + +** *Warning.* In the future releases we intend to introduce the range interface + in `optional`, so that `std::ranges::range>` will be `true`. + This may affect the overload resolution in programs that make decisions based + on predicates such as `std::ranges::range`. For instance, the following code + will start behaving differently: + ++ + + template + void serialize(T const& v) + { + if constexpr (std::ranges::range) + serialize_as_range(v); + else if constexpr (custom::is_optional_like) + serialize_as_optional(v); + else + serialize_as_value(v); + } + + + * boost_phrase:library[Unordered,/libs/unordered/]: ** Fixed the returned value of range insertion in concurrent containers (boost_gh:pr[unordered,344]). From 476aaf328e7c091ea88fb5beee03914714eb41e2 Mon Sep 17 00:00:00 2001 From: Andrzej Krzemienski Date: Wed, 4 Mar 2026 08:09:13 +0100 Subject: [PATCH 2/2] Implement Peter's suggestions --- release-notes/boost_1_91_0.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/release-notes/boost_1_91_0.adoc b/release-notes/boost_1_91_0.adoc index 50cf78d..443364b 100644 --- a/release-notes/boost_1_91_0.adoc +++ b/release-notes/boost_1_91_0.adoc @@ -85,7 +85,7 @@ because manipulating it outside of the library code can lead to undefined behavi `constexpr` support: *** In C++11, some constructors and `const`-qualified accessors become usable - in compile-time contexts (are ['core constant expressions]) for types + in compile-time contexts (are _core constant expressions_) for types satisfying certain constraints. *** In C++14 even some mutating operations become core constant expressions (those that do not require changing the state of `optional` from not having a value to @@ -96,16 +96,16 @@ because manipulating it outside of the library code can lead to undefined behavi This addresses issues https://github.com/boostorg/optional/issues/132[#132] and https://github.com/boostorg/optional/issues/143[#143]. -** *Breaking change.* In the said implementation, abandoned the mechanism for customizing +** *Breaking change.* Abandoned the mechanism for customizing `swap`. Hardly anyone knows about this mechanism and it was never documented. -** In the said implementation, applied a couple of small changes to get closer to the interface of `std::optional`: +** Applied a couple of small changes to get closer to the interface of `std::optional`: *** Enabled syntax `o = {}` for putting optional objects to no-value state. *** Enabled syntax `o.value_or({})`, which uses a default-constructed `T`. *** Construct `o = u`, where `o` is of type `optional` and `u` is of type `U` convertible to `T`, does not create a temporary `T`. -** In the said implementation, added a conversion from `optional&` to `optional`. This addresses https://github.com/boostorg/optional/issues/142[#142]. +** Added a conversion from `optional&` to `optional`. This addresses https://github.com/boostorg/optional/issues/142[#142]. ** `none_t` is now `std::equality_comparable`, which means that `none_t` and `optional` model concept `std::equality_comparable_with` (for `std::equality_comparable` `T`), @@ -113,7 +113,7 @@ This addresses issues https://github.com/boostorg/optional/issues/132[#132] and ** *Warning.* In the future releases we intend to introduce the range interface in `optional`, so that `std::ranges::range>` will be `true`. - This may affect the overload resolution in programs that make decisions based + This will affect the overload resolution in programs in certain cases that make decisions based on predicates such as `std::ranges::range`. For instance, the following code will start behaving differently: