The Master branch is now CLOSED for the beta release
Please do not commit or merge to the master branch The Beta RC1s will be available later today. — The release managers.
On Thu, Nov 6, 2025 at 10:30 AM Marshall Clow via Boost < boost@lists.boost.org> wrote:
Please do not commit or merge to the master branch
The Beta RC1s will be available later today.
An interesting edge case came up. In Kona, WG21 voted to rename nontype:
10. Apply the changes in P3774R1 (Rename std::nontype, and make it broadly useful) to the C++ working paper. This addresses ballot comments FR-021-218 and FR-019-210. https://open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3774r1.html
Boost.Compat has nontype: https://github.com/boostorg/compat/blob/develop/include/boost/compat/nontype... Pretty please, with a cherry on top, could the author have permission to rename this type for this release, so it is aligned with the standard from the get-go? Thanks
On Nov 8, 2025, at 7:16 AM, Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Thu, Nov 6, 2025 at 10:30 AM Marshall Clow via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Please do not commit or merge to the master branch
The Beta RC1s will be available later today.
An interesting edge case came up. In Kona, WG21 voted to rename nontype:
10. Apply the changes in P3774R1 (Rename std::nontype, and make it broadly useful) to the C++ working paper. This addresses ballot comments FR-021-218 and FR-019-210. https://open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3774r1.html
Boost.Compat has nontype: https://github.com/boostorg/compat/blob/develop/include/boost/compat/nontype...
Pretty please, with a cherry on top, could the author have permission to rename this type for this release, so it is aligned with the standard from the get-go?
I agree that this should be changed for the 1.90 release. For the 1.90 beta release? I’m less sure that this is necessary. — Marshall P.S. When was boost::nontype added?
Marshall Clow wrote:
P.S. When was boost::nontype added?
There is no boost::nontype. There is boost::compat::nontype_t, which appeared as part of the public API of boost::compat::function_ref: https://www.boost.org/doc/libs/1_89_0/libs/compat/doc/html/compat.html#funct... Despite being defined by function_ref.hpp, it wasn't actually documented, though. The corresponding variable template boost::compat::nontype wasn't provided. For this release, I moved nontype_t to its own public header and added nontype: https://www.boost.org/doc/libs/1_90_0_beta1/libs/compat/doc/html/compat.html... But then, the committee renamed it. I'm not quite sure what to do now. Renaming the newly added header and the type and variable within is an option but I'm not entirely sure that the committee won't change it again; there are indications that it might to do so. Maybe we should just go back to what 1.89 had and postpone the changes.
On 15 Nov 2025 14:33, Peter Dimov via Boost wrote:
Marshall Clow wrote:
P.S. When was boost::nontype added?
There is no boost::nontype.
There is boost::compat::nontype_t, which appeared as part of the public API of boost::compat::function_ref:
https://www.boost.org/doc/libs/1_89_0/libs/compat/doc/html/compat.html#funct...
Despite being defined by function_ref.hpp, it wasn't actually documented, though.
The corresponding variable template boost::compat::nontype wasn't provided.
For this release, I moved nontype_t to its own public header and added nontype:
https://www.boost.org/doc/libs/1_90_0_beta1/libs/compat/doc/html/compat.html...
But then, the committee renamed it.
I'm not quite sure what to do now. Renaming the newly added header and the type and variable within is an option but I'm not entirely sure that the committee won't change it again; there are indications that it might to do so.
Maybe we should just go back to what 1.89 had and postpone the changes.
If there isn't a reasonably firm specification and choice of a name yet, I'd say don't expose the feature in Boost.Compat.
Andrey Semashev wrote:
If there isn't a reasonably firm specification and choice of a name yet, I'd say don't expose the feature in Boost.Compat.
Breaking code that used to work in previous releases without a deprecation period is not something we usually do, and we definitely don't introduce such changes between the beta and the release.
On 15 Nov 2025 20:19, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
If there isn't a reasonably firm specification and choice of a name yet, I'd say don't expose the feature in Boost.Compat.
Breaking code that used to work in previous releases without a deprecation period is not something we usually do, and we definitely don't introduce such changes between the beta and the release.
I thought you said the new variable template was introduced in this release? What I'm saying is remove what was added in this release (boost::compat::nontype). If boost::compat::nontype_t was previously released, keep it, but maybe add a release note saying we might rename or remove it in the next release.
participants (4)
-
Andrey Semashev -
Marshall Clow -
Peter Dimov -
Vinnie Falco