Spirit requires C++23 for questionable reasons
This new maintainer of Spirit has bumped up the language requirements to C++23, for what is in my opinion a gratuitous reason. To serve the widest audience I think it is best when libraries use the lowest version of C++ which is practical, and only adopt new language features when doing so improves the public API or offers a significant benefit to the user experience. While it is true that newer language features can make it easier for the maintainer to express the implementation, we make sacrifices (like writing `typename...type` instead of using the newer type trait aliases) for the convenience of users. This bump to C++23, which came without warning, has affected Boost.MQTT5 which must now scramble to fix itself before the next release. There should have been a warning for a version first. The Spirit author's rationale can be seen in this GitHub issue: https://github.com/boostorg/mqtt5/issues/36 Quoted here for convenience:
There's one political reason that I didn't mention: young people. Why would a high school student who likes to experiment with C++ consider some obsolete (C++17) library as attractive? Boost is dying and we're doomed if we don't use bleeding edge features to attract young people. You might think this is some kind of joke but I believe this is the right way to proceed.
Young people will avoid contribution to the existing library if it sticks to the C++ standard that is now obsolete for 2 versions. That was my feeling when I saw a C++03 library when I was a high school student. I'm 30 years old now and still think the same.
My goal is to revitalize C++. It is impossible without gathering contributions from the young people. Some people write C++ for business, while some people write C++ because it's genuinely fun to hack. That's the difference. It's the same reason that Rust is getting wider audience than C++.
Many Japanese University students think otherwise. I have active connections to the young community and they actually empathize with me. Thanks for the video anyways, that is a good evidence that western, agitated-by-businessman young people are very different than my colleagues.
Thanks
Am 11.09.25 um 13:45 schrieb Vinnie Falco via Boost:
This new maintainer of Spirit has bumped up the language requirements to C++23, for what is in my opinion a gratuitous reason. To serve the widest audience I think it is best when libraries use the lowest version of C++ which is practical, and only adopt new language features when doing so improves the public API or offers a significant benefit to the user experience. While it is true that newer language features can make it easier for the maintainer to express the implementation, we make sacrifices (like writing `typename...type` instead of using the newer type trait aliases) for the convenience of users. I agree with you.
If the author/maintainer decides that there is enough benefit of raising the required C++ standard then it is his authority though. I do think that raising the required standard from C++03 to C++23 looks to much. But then again I don't maintain the library so this is only an opinion.
This bump to C++23, which came without warning, has affected Boost.MQTT5 which must now scramble to fix itself before the next release. There should have been a warning for a version first. IIRC we had guideline of announcing breaking changes, like this, 1-2 releases in advance. This didn't happen as it seems.
I also don't see any machine-readable statement of the required C++ standard. The README says C++23 & 26 but the meta-json and compile-requirements in the build files haven't been updated.
Alexander Grund wrote:
I also don't see any machine-readable statement of the required C++ standard. The README says C++23 & 26 but the meta-json and compile-requirements in the build files haven't been updated.
That's because boostorg/spirit holds three libraries, one of which requires C++03, the other I'm not sure what, and the third (X3, the one under discussion) used to require C++17. We're discussing how to split these three into their own repositories in https://github.com/boostorg/spirit/issues/795 but you should know that because it's your issue. :-)
On September 11, 2025 4:02:49 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Alexander Grund wrote:
I also don't see any machine-readable statement of the required C++ standard. The README says C++23 & 26 but the meta-json and compile-requirements in the build files haven't been updated.
That's because boostorg/spirit holds three libraries, one of which requires C++03, the other I'm not sure what, and the third (X3, the one under discussion) used to require C++17.
Thing is, as I've been told recently, only X3 is currently being maintained. The other two are unmaintained, as I understand, including no bug fixes. So, unless you're fine with depending on unmaintained code, Spirit == X3, and you are affected by this change.
On Thu, Sep 11, 2025, at 7:01 PM, Andrey Semashev via Boost wrote:
On September 11, 2025 4:02:49 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Alexander Grund wrote:
I also don't see any machine-readable statement of the required C++ standard. The README says C++23 & 26 but the meta-json and compile-requirements in the build files haven't been updated.
That's because boostorg/spirit holds three libraries, one of which requires C++03, the other I'm not sure what, and the third (X3, the one under discussion) used to require C++17.
Thing is, as I've been told recently, only X3 is currently being maintained. The other two are unmaintained, as I understand, including no bug fixes. So, unless you're fine with depending on unmaintained code, Spirit == X3, and you are affected by this change.
Oh wow. That's a deal-breaker to me, because X3 is experimental AND has significant issues. Some things are hard/impossible to port from Qi to X3 - exacerbated by the (spurious?) decision of a dev to not only "not implement" a qi::lazy pendant, but even go so far as to deprecate the essential building block `x3::any_parser` - which is like a type-erased x3::rule (https://github.com/boostorg/spirit/issues/530#issuecomment-3254447450) If the problem is that that Qi is not maintained, THAT should be fixed, as it is by far the most mature component in the Spirit library. Source: be me and volunteer Spirit support (mailing list and Stackoverflow) for the larger part of the last 2 decades. Seth (sehe)
On 9/12/25 1:11 AM, Seth via Boost wrote:
Oh wow. That's a deal-breaker to me, because X3 is experimental AND has significant issues.
Some things are hard/impossible to port from Qi to X3 - exacerbated by the (spurious?) decision of a dev to not only "not implement" a qi::lazy pendant, but even go so far as to deprecate the essential building block `x3::any_parser` - which is like a type-erased x3::rule (https://github.com/boostorg/spirit/issues/530#issuecomment-3254447450)
If the problem is that that Qi is not maintained, THAT should be fixed, as it is by far the most mature component in the Spirit library.
Source: be me and volunteer Spirit support (mailing list and Stackoverflow) for the larger part of the last 2 decades.
Seth, you're the best person I can think of for maintaining the Qi codebase, if you are willing to do it. Regards, -- Joel de Guzman Cycfi Research, Inc.
Andrey Semashev wrote:
Thing is, as I've been told recently, only X3 is currently being maintained. The other two are unmaintained, as I understand, including no bug fixes. So, unless you're fine with depending on unmaintained code,
Many people do that, most of them indirectly via Serialization.
Alexander Grund Wrote:
If the author/maintainer decides that there is enough benefit of raising the required C++ standard then it is his authority though.
Perhaps it's time to rethink that policy. Boost already has a bad reputation for introducing breaking changes and increasing the language requirement beyond the latest compiler default version seems likely to break a lot of code currently using it. It's one thing for a library to add optional new features or functionality that exploits newer language standards, but increasing the baseline version requirement should not be seen through the same lens. As it pertains to soliciting community engagement, I fear reinforcing Boost's reputation for breaking stuff does more harm than any good that would come from simply being on the latest language standard. If a library maintainer is using advocacy as their rationale for doing this, then I think it's fair grounds for a wider discussion about what really *is* in the best interests of Boost. Matt
Before we mire in the weeds about what is or isn't harmful to Boost's reputation, we should wait for actual complaints to come in. A core tenet of Boost is unrestricted author freedom. I've seen people in multiple cases talk about not upgrading Boost because of breaking changes in Asio, so I don't think this results in as much damage as is being purported here. Right now the only people mad about the X3 change are just Boost authors. Also keep in mind, we even have trouble shilling new libraries on reddit because the reputation of our review process is greatly damaged. So if you wanna talk about reputation, there's a lot of other aspects to it than one niche library that likely doesn't have many production users to begin with. - Christian
On Thu, Sep 11, 2025 at 6:32 PM Christian Mazakas via Boost <boost@lists.boost.org> wrote:
Right now the only people mad about the X3 change are just Boost authors.
And that doesn't count? Maybe those other project should migrate to https://www.boost.org/library/latest/parser/, no?
2025年9月12日(金) 2:50 Vinnie Falco via Boost <boost@lists.boost.org>:
On Thu, Sep 11, 2025 at 10:41 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:
Is this new maintainer of Spirit subscribed to the mailing list?
I am subscribed. The C++23 modernization starter PR was merged after explicit approval from Joel de Guzman, Spirit's author and maintainer. link: https://github.com/boostorg/spirit/pull/807#issuecomment-3251345470
To serve the widest audience I think it is best when libraries use the lowest version of C++ which is practical, and only adopt new language features when doing so improves the public API or offers a significant benefit to the user experience.
My PRs improve the public API and offer a significant benefit to the users. The rationale is thoroughly described in each of the pull requests. https://github.com/boostorg/spirit/pull/807 https://github.com/boostorg/spirit/issues/809
On 9/12/25 2:12 AM, Nana Sakisaka via Boost wrote:
2025年9月12日(金) 2:50 Vinnie Falco via Boost <boost@lists.boost.org>:
On Thu, Sep 11, 2025 at 10:41 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:
Is this new maintainer of Spirit subscribed to the mailing list?
I am subscribed.
The C++23 modernization starter PR was merged after explicit approval from Joel de Guzman, Spirit's author and maintainer.
link: https://github.com/boostorg/spirit/pull/807#issuecomment-3251345470
To serve the widest audience I think it is best when libraries use the lowest version of C++ which is practical, and only adopt new language features when doing so improves the public API or offers a significant benefit to the user experience. My PRs improve the public API and offer a significant benefit to the users. The rationale is thoroughly described in each of the pull requests.
Due to some backlash with this PR, mostly due to breaking changes. We should probably ease up and rethink what we are doing here. Boost thrives on consensus, and the discussions seem to be going in a negative direction, which should be addressed both in the PR and in this mailing list. I urge the parties to raise the issues the the PR: https://github.com/boostorg/spirit/pull/807 FWIW, my position is that I am all for modernizing and moving to C++23, but it should be done carefully and with consideration to users of Spirit X3 and Boost in general. Regards, -- Joel de Guzman Cycfi Research, Inc.
2025年9月12日(金) 4:17 Joel de Guzman via Boost <boost@lists.boost.org>:
FWIW, my position is that I am all for modernizing and moving to C++23, but it should be done carefully and with consideration to users of Spirit X3 and Boost in general.
This is exactly the reason why I have been suspending the merge of `develop` into `master` for 7 months. Everything is happening only on the `develop` branch now. It has some breaking changes, including unannounced ones, because it's just got started. That said, it seems like Joel is suggesting further discussion to be continued on PR #807. Please follow the link.
I urge the parties to raise the issues the the PR: https://github.com/boostorg/spirit/pull/807
On Thu, Sep 11, 2025 at 12:17 PM Joel de Guzman via Boost < boost@lists.boost.org> wrote:
I urge the parties to raise the issues the the PR:
Thank you and consider posting to the boost-users mailing list soliciting feedback and to provide a heads-up in advance of potential breaking changes? Regards
On 9/12/25 3:29 AM, Vinnie Falco wrote:
On Thu, Sep 11, 2025 at 12:17 PM Joel de Guzman via Boost <boost@lists.boost.org> wrote:
I urge the parties to raise the issues the the PR:
Thank you and consider posting to the boost-users mailing list soliciting feedback and to provide a heads-up in advance of potential breaking changes?
Absolutely. I think the problem is communication, which seems to be happening everywhere now, including Github and Slack(?). Regards, -- Joel de Guzman Cycfi Research, Inc.
On Thu, Sep 11, 2025 at 12:38 PM Joel de Guzman <djowel@gmail.com> wrote:
...I think the problem is communication, which seems to be happening everywhere now, including Github and Slack(?).
Yes and to be specific, the communication is happening: * On the developer's mailing list, where other Boost authors are being informed of potential breakage using the customary channel. * On an MQTT5 GitHub issue for breakage of develop ( https://github.com/boostorg/mqtt5/issues/36) * On a Spirit GitHub issue for a branding issue ( https://github.com/boostorg/spirit/issues/828) * On Slack, for real-time discussion on how to minimize the harm for existing users * And, now proposed the Boost Users mailing list to inform downstream users of Boost of potential breakage Thanks
2025年9月12日(金) 4:50 Vinnie Falco via Boost <boost@lists.boost.org>:
* On a Spirit GitHub issue for a branding issue ( https://github.com/boostorg/spirit/issues/828)
This is not the issue about "branding". The only account who cares about "branding" on the issue is the person who has a relationship with the C++ Alliance. The issue is about a suggestion for adding a cute mascot to Spirit's documentation, while not interfering with the organization logo. Spirit's documentation is very stale and needs to be updated. I suggested the above idea as part of the improvement, which would soften the tone of the technical documentation thus ultimately making the newcomers feel more fun reading the docs.
On Thu, Sep 11, 2025 at 1:03 PM Nana Sakisaka via Boost < boost@lists.boost.org> wrote:
The issue is about a suggestion for adding a cute mascot to Spirit's documentation, while not interfering with the organization logo.
Yes that is benign.
Spirit's documentation is very stale and needs to be updated. I suggested the above idea as part of the improvement, which would soften the tone of the technical documentation thus ultimately making the newcomers feel more fun reading the docs.
What else is involved in this update of the stale Spirit documentation? Thanks
2025年9月12日(金) 5:05 Vinnie Falco <vinnie.falco@gmail.com>:
Spirit's documentation is very stale and needs to be updated. I suggested
the above idea as part of the improvement, which would soften the tone of the technical documentation thus ultimately making the newcomers feel more fun reading the docs.
What else is involved in this update of the stale Spirit documentation?
There is a long-standing request to make the X3 docs more "visible" to users. https://github.com/boostorg/spirit/issues/795 It stems from our serious mistake that V2 had been displayed on the index page for years, despite that X3 had been the primary place of development for at least 7 years. ("7 years" is the duration that X3 had been placed at the topmost section of README). Many other subpages of the documentation are also stale, but I can't easily provide a comprehensive list of obsolete sections right now. That essentially requires me to re-check the entire documentation, which is essentially the same as working on a fresh PR. As Joel suggested, please continue the discussion on the GitHub link I mentioned above. We should stop splitting our discussion into various places. P.S. I originally replied only to Vinnie without including the list. I'm not used to the email interface, apologies.
On Thu, Sep 11, 2025 at 1:41 PM Nana Sakisaka <aroma.slope.seven@gmail.com> wrote:
There is a long-standing request to make the X3 docs more "visible" to users
Oh... yes, that is a problem. I myself did not realize that Spirit was actually three separate libraries, and that the move to C++23 only affected one of them (?) My opinion, this needs to be split up physically into individual libraries so they can each evolve and be maintained independently (or not maintained, such as in the case of old X3 maybe?) We have been working on supporting the Asciidoctor and Antora toolchains to provide a modern option for Boost library documentation, as the current Quickbook is receiving little maintenance (in some cases no maintenance). Quickbook is a long-term existential risk for Boost library documentation. Antora looks like this (with our custom UI and stylesheets): https://www.boost.org/doc/libs/master/doc/antora/url/index.html A benefit is that Asciidoctor is a popular markdown format which enjoys wide support. GitHub for example, renders previews for adoc files as you can see here: https://github.com/boostorg/json/blob/develop/README.adoc And the Alliance provides infrastructure so that pull requests show documentation previews before they are merged: https://github.com/boostorg/url/pull/861#issuecomment-2328039431 As Joel suggested, please continue the discussion on the GitHub link I
mentioned above. We should stop splitting our discussion into various places.
Joel suggested both GitHub issues and the mailing list. GitHub issues have their place yet they lack the greater visibility to the rest of the contributor community. I think a discussion of splitting up libraries and available new tooling for documentation is something of interest and important to a wider audience. I apologize if I came across as heavy handed in some of those issues. I think the problem here is that months of changes and intentions which impact other things came out of nowhere. Perhaps when a new maintainer is appointed for a library there could be a formal introduction to the mailing list, and the new maintainer receives some kind of instruction so they can learn about customs such as the mailing list, the desire to avoid breaking existing users, and the encouragement to maintain a two-way dialog when making big changes. Maybe it is not too late to do this? Thanks
Perhaps when a new maintainer is appointed for a library there could be a formal introduction to the mailing list, and the new maintainer receives some kind of instruction so they can learn about customs such as the mailing list, the desire to avoid breaking existing users, and the encouragement to maintain a two-way dialog when making big changes. Maybe it is not too late to do this?
Such a great idea for making the ML a welcoming place; I love this :D Also Nana, I am a very naive user of Boost Spirit/X3 (that is without sehe's help I would never have gotten far) so I would be happy to serve as a candid reader of your new docs :3 If I learned something from the ML it is that no unique channel of communication will be able to bring us together ;) That being said, I will go to your Github link for the chat. Welcome Nana! Arno
2025年9月12日(金) 6:00 Vinnie Falco <vinnie.falco@gmail.com>:
On Thu, Sep 11, 2025 at 1:41 PM Nana Sakisaka <aroma.slope.seven@gmail.com> wrote:
There is a long-standing request to make the X3 docs more "visible" to users
Oh... yes, that is a problem. I myself did not realize that Spirit was actually three separate libraries, and that the move to C++23 only affected one of them (?)
My opinion, this needs to be split up physically into individual libraries so they can each evolve and be maintained independently (or not maintained, such as in the case of old X3 maybe?)
Spirit consists of 3 individual libraries: - Spirit.Classic, dormant for 20 years, supports C++03. - Spirit.V2 (Qi & Karma & Lex), not actively maintained, supports C++11. - Spirit.X3, technically being the primary development target since 2014; supports C++23 & C++26. The recent breakage only affects the `develop` branch of Spirit.X3 only.
We have been working on supporting the Asciidoctor and Antora toolchains to provide a modern option for Boost library documentation, as the current Quickbook is receiving little maintenance (in some cases no maintenance). Quickbook is a long-term existential risk for Boost library documentation. Antora looks like this (with our custom UI and stylesheets):
I have professional skills on AsciiDoc and I actually plan to migrate the entire Spirit documentation to AsciiDoc. Although we haven't made a consensus on which framework to choose, I believe AsciiDoc is the best and I plan to submit PR. You have my word on this, it's one of my initial motivations for volunteering to become the maintainer in the first place. https://github.com/boostorg/spirit/issues/800#issuecomment-2857784154 Despite that I posted a rather strong comment, Joel accepted me to become the maintainer and I'm willing to fulfill my responsibility for that. I apologize if I came across as heavy handed in some of those issues. I
think the problem here is that months of changes and intentions which impact other things came out of nowhere. Perhaps when a new maintainer is appointed for a library there could be a formal introduction to the mailing list, and the new maintainer receives some kind of instruction so they can learn about customs such as the mailing list, the desire to avoid breaking existing users, and the encouragement to maintain a two-way dialog when making big changes. Maybe it is not too late to do this?
I believe the actual problem is that almost every open source developers naturally has the instinct that the GitHub repository is the primary place for such technical discussion. I honestly think that every developer who is affected by the breaking changes on the **`develop`** branch should immediately subscribe to the repository and post a comment on the PR. Vinnie, IIRC you were one of the modern developers who disliked the mailing list interface, no? I personally never use email during my OSS work except for Boost. Don't you feel stressed by this interface? I assume that's why you repeatedly promote Slack. I don't like this email interface at all. I broke the silence after 10 years of subscription because Vinnie mentioned my name on the list. (No offense. I think it was the right timing.)
2025年9月12日(金) 6:00 Vinnie Falco <vinnie.falco@gmail.com>:
My opinion, this needs to be split up physically into individual libraries so they can each evolve and be maintained independently (or not maintained, such as in the case of old X3 maybe?)
At least 3 members: Peter Dimov, Joel de Guzman and Nana Sakisaka have reached a strong consensus on splitting Spirit subcomponents into 3 distinct repositories. https://github.com/boostorg/spirit/issues/795#issuecomment-3276591805 2025年9月12日(金) 6:26 Nana Sakisaka <aroma.slope.seven@gmail.com>:
2025年9月12日(金) 6:00 Vinnie Falco <vinnie.falco@gmail.com>:
On Thu, Sep 11, 2025 at 1:41 PM Nana Sakisaka < aroma.slope.seven@gmail.com> wrote:
There is a long-standing request to make the X3 docs more "visible" to users
Oh... yes, that is a problem. I myself did not realize that Spirit was actually three separate libraries, and that the move to C++23 only affected one of them (?)
My opinion, this needs to be split up physically into individual libraries so they can each evolve and be maintained independently (or not maintained, such as in the case of old X3 maybe?)
Spirit consists of 3 individual libraries: - Spirit.Classic, dormant for 20 years, supports C++03. - Spirit.V2 (Qi & Karma & Lex), not actively maintained, supports C++11. - Spirit.X3, technically being the primary development target since 2014; supports C++23 & C++26.
The recent breakage only affects the `develop` branch of Spirit.X3 only.
We have been working on supporting the Asciidoctor and Antora toolchains to provide a modern option for Boost library documentation, as the current Quickbook is receiving little maintenance (in some cases no maintenance). Quickbook is a long-term existential risk for Boost library documentation. Antora looks like this (with our custom UI and stylesheets):
I have professional skills on AsciiDoc and I actually plan to migrate the entire Spirit documentation to AsciiDoc. Although we haven't made a consensus on which framework to choose, I believe AsciiDoc is the best and I plan to submit PR.
You have my word on this, it's one of my initial motivations for volunteering to become the maintainer in the first place. https://github.com/boostorg/spirit/issues/800#issuecomment-2857784154 Despite that I posted a rather strong comment, Joel accepted me to become the maintainer and I'm willing to fulfill my responsibility for that.
I apologize if I came across as heavy handed in some of those issues. I
think the problem here is that months of changes and intentions which impact other things came out of nowhere. Perhaps when a new maintainer is appointed for a library there could be a formal introduction to the mailing list, and the new maintainer receives some kind of instruction so they can learn about customs such as the mailing list, the desire to avoid breaking existing users, and the encouragement to maintain a two-way dialog when making big changes. Maybe it is not too late to do this?
I believe the actual problem is that almost every open source developers naturally has the instinct that the GitHub repository is the primary place for such technical discussion. I honestly think that every developer who is affected by the breaking changes on the **`develop`** branch should immediately subscribe to the repository and post a comment on the PR.
Vinnie, IIRC you were one of the modern developers who disliked the mailing list interface, no? I personally never use email during my OSS work except for Boost. Don't you feel stressed by this interface? I assume that's why you repeatedly promote Slack. I don't like this email interface at all. I broke the silence after 10 years of subscription because Vinnie mentioned my name on the list. (No offense. I think it was the right timing.)
On Thu, Sep 11, 2025 at 2:26 PM Nana Sakisaka <aroma.slope.seven@gmail.com> wrote:
I have professional skills on AsciiDoc and I actually plan to migrate the entire Spirit documentation to AsciiDoc. Although we haven't made a consensus on which framework to choose, I believe AsciiDoc is the best and I plan to submit PR.
Yes, and note the following: asciidoc: the name of the markdown format asciidoctor: the name of a tool which renders asciidoc antora: a publishing framework which renders multipage documentation sets, in asciidoc format Antora is from the same author as Asciidoctor and it uses the same markdown format. The difference is that regular asciidoctor usually leads to 1-page documentation such as: https://boost.org/libs/describe Whereas Antora is designed for multi-page output such as: https://www.boost.org/libs/url Given the size of the documentation of each of the libraries in Spirit I would advise Antora (which as I said, uses asciidoc markdownj).
I believe the actual problem is that almost every open source developers naturally has the instinct that the GitHub repository is the primary place for such technical discussion. I honestly think that every developer who is affected by the breaking changes on the **`develop`** branch should immediately subscribe to the repository and post a comment on the PR.
On the one hand, the specific technical aspects of the breakage of backward compatibility are probably best handled in the corresponding GitHub issue. However there are also social aspects that merit discussion and those are best placed on the list. Conversations on GitHub are not discoverable in the same way that posts to the mailing lists are discoverable via the archives. With the mailing list, every contributor also has the option for a locally searchable archive unlike GitHub issues.
Vinnie, IIRC you were one of the modern developers who disliked the mailing list interface, no? I personally never use email during my OSS work except for Boost. Don't you feel stressed by this interface?
I'm not personally opposed to the mailing list yet it does have disadvantages. Signing up is slow, the archive uses a completely different interface and if you subscribe after a discussion begins you don't have the context in your inbox. For example if you want to submit a review after the review period starts and you subscribe then, you do not have the original review email to reply to. Also I get the sense that mailing lists are declining in popularity with the hypothetical youthful contributors. On the other hand, the mailing list has distinct advantages. You can use one program to keep track of all your open source projects. You can control notification settings across your devices. You get a local archive and you can filter messages. It spans all development topics across all libraries.
I assume that's why you repeatedly promote Slack.
Slack is a completely different communication medium. It is real time discussion which is well-suited for collaboration. It is not so well suited for discussing topics which involve all Boost stakeholders. You can't practically search through old discussions. It is a different thing, yet it is also popular because of its immediacy. It also handles images and formatted text, so it is easier to share code snippets and links to offsite resources have embedded previews. Here, it has an advantage over the mailing list. You can also do a voice call and share screen at just the click of a button.
I don't like this email interface at all. I broke the silence after 10 years of subscription because Vinnie mentioned my name on the list. (No offense. I think it was the right timing.)
Well, you've been subscribed longer than me :) quite the lurk. How do you feel about a web-based front end to the mailing list instead of your email client? Something like this maybe: https://lists.boost.org/archives/list/boost@lists.boost.org/ Thanks
On 9/12/25 5:44 AM, Vinnie Falco via Boost wrote:
On Thu, Sep 11, 2025 at 2:26 PM Nana Sakisaka<aroma.slope.seven@gmail.com> wrote:
I have professional skills on AsciiDoc and I actually plan to migrate the entire Spirit documentation to AsciiDoc. Although we haven't made a consensus on which framework to choose, I believe AsciiDoc is the best and I plan to submit PR.
Yes, and note the following:
asciidoc: the name of the markdown format asciidoctor: the name of a tool which renders asciidoc antora: a publishing framework which renders multipage documentation sets, in asciidoc format
Antora is from the same author as Asciidoctor and it uses the same markdown format. The difference is that regular asciidoctor usually leads to 1-page documentation such as:https://boost.org/libs/describe Whereas Antora is designed for multi-page output such as:https://www.boost.org/libs/url Given the size of the documentation of each of the libraries in Spirit I would advise Antora (which as I said, uses asciidoc markdownj).
I am all for Asciidoc and Antora. I use that now in all my recent libraries. Example: https://cycfi.github.io/q/q/v1.5-dev/reference/synth.html Cheers, -- Joel de Guzman Cycfi Research, Inc.
Vinnie, IIRC you were one of the modern developers who disliked the mailing list interface, no? I personally never use email during my OSS work except for Boost. Don't you feel stressed by this interface? I assume that's why you repeatedly promote Slack. I don't like this email interface at all. I broke the silence after 10 years of subscription because Vinnie mentioned my name on the list. (No offense. I think it was the right timing.)
DISCLAIMER: Boomer speaking ;-) Slack confuses the hell out of me. It pretends to have threads, but it doesn't. It's good for quick whatsapp-like interactions, I do peruse the mrdocs channel.. But not for "serious" debate. I am fine with the mailing list, but then I drive a stick. I gather I am in the minority on this. I don't want Boost to follow the manual gearbox into extinction. I like a fully threaded medium. A forum would work if it has tree-like threads. Has anybody played with GH Discussion? J-L
On Thu, Sep 11, 2025 at 4:41 PM Jean-Louis Leroy <jl@leroy.nyc> wrote:
I like a fully threaded medium. A forum would work if it has tree-like threads.
You mean like this? https://lists.boost.org/archives/list/boost@lists.boost.org/thread/K3EQLEQJH... Thanks
2025年9月12日(金) 4:17 Joel de Guzman via Boost <boost@lists.boost.org>:
Due to some backlash with this PR, mostly due to breaking changes. We should probably ease up and rethink what we are doing here. Boost thrives on consensus, and the discussions seem to be going in a negative direction, which should be addressed both in the PR and in this mailing list.
I urge the parties to raise the issues the the PR:
https://github.com/boostorg/spirit/pull/807
FWIW, my position is that I am all for modernizing and moving to C++23, but it should be done carefully and with consideration to users of Spirit X3 and Boost in general.
Re-quoting this message to inform the list that further discussions should take place on the specific link Joel mentioned.
On 12 Sep 2025 01:06, Nana Sakisaka via Boost wrote:
2025年9月12日(金) 4:17 Joel de Guzman via Boost <boost@lists.boost.org>:
Due to some backlash with this PR, mostly due to breaking changes. We should probably ease up and rethink what we are doing here. Boost thrives on consensus, and the discussions seem to be going in a negative direction, which should be addressed both in the PR and in this mailing list.
I urge the parties to raise the issues the the PR:
https://github.com/boostorg/spirit/pull/807
FWIW, my position is that I am all for modernizing and moving to C++23, but it should be done carefully and with consideration to users of Spirit X3 and Boost in general.
Re-quoting this message to inform the list that further discussions should take place on the specific link Joel mentioned.
Personally, it looks like there's confusion as to which Spirit version serves which purpose, and in particular, which version should be considered production-ready by users. I think, the decision needs to be made by the Spirit maintainers and then announced here and in release notes. I do not think the PR comments are the appropriate place to discuss this decision (if such as discussion should happen) because (a) this goes beyond the X3 refactoring work done in the PR and (b) the PR comments are not as discoverable as this ML and release notes.
On 9/12/25 7:11 AM, Andrey Semashev via Boost wrote:
On 12 Sep 2025 01:06, Nana Sakisaka via Boost wrote:
2025年9月12日(金) 4:17 Joel de Guzman via Boost <boost@lists.boost.org>:
Due to some backlash with this PR, mostly due to breaking changes. We should probably ease up and rethink what we are doing here. Boost thrives on consensus, and the discussions seem to be going in a negative direction, which should be addressed both in the PR and in this mailing list.
I urge the parties to raise the issues the the PR:
https://github.com/boostorg/spirit/pull/807
FWIW, my position is that I am all for modernizing and moving to C++23, but it should be done carefully and with consideration to users of Spirit X3 and Boost in general. Re-quoting this message to inform the list that further discussions should take place on the specific link Joel mentioned. Personally, it looks like there's confusion as to which Spirit version serves which purpose, and in particular, which version should be considered production-ready by users. I think, the decision needs to be made by the Spirit maintainers and then announced here and in release notes. I do not think the PR comments are the appropriate place to discuss this decision (if such as discussion should happen) because (a) this goes beyond the X3 refactoring work done in the PR and (b) the PR comments are not as discoverable as this ML and release notes.
Agreed. For any major update, I suggest starting a discussion in Github's discussion pages and informing the list about it. That being said, I urge the Boost community to maintain a kind and welcoming tone. That was not the case in the message that started this thread. Maintaining a library is NOT a trivial task, everyone knows that, and it is disheartening to see maintainers leave because of the toxicity. Here's one from @Kolejey from May 8: "The main reason I've stopped working on improvements is because I got yelled pretty much every time I fix a bug or change some internal stuff that no one should've relied on. And I get their viewpoint, Boost nowadays is seen as a collection of mostly legacy battle- tested libraries, a project uses Boost because it have used it for a long while and people that maintain it don't want their working code been disturbed." And this reflects the scenario we have now, again. Regards, -- Joel de Guzman Cycfi Research, Inc.
On Thu, Sep 11, 2025 at 6:05 PM Joel de Guzman via Boost < boost@lists.boost.org> wrote:
That being said, I urge the Boost community to maintain a kind and welcoming tone. That was not the case in the message that started this thread. Maintaining a library is NOT a trivial task, everyone knows that, and it is disheartening to see maintainers leave because of the toxicity. Here's one from @Kolejey from May 8:
"The main reason I've stopped working on improvements is because I got yelled pretty much every time I fix a bug or change some internal stuff that no one should've relied on. And I get their viewpoint, Boost nowadays is seen as a collection of mostly legacy battle- tested libraries, a project uses Boost because it have used it for a long while and people that maintain it don't want their working code been disturbed."
And this reflects the scenario we have now, again.
Indeed. As a community, we failed here. And I'm including myself in this as well. We were so quick to get riled up and argue and bicker with each other, that we missed the obvious solutions and steps. We should've simply shown the new maintainer how to use boostdep, how to do regression testing across the list of reported libraries and then instructed them on how we roll out large deprecating changes, similar to the C++03 deprecation. We could've avoided a lot of pain and drama. Alas, the cost of wisdom is foolishness and at the very least, I know what to do in the future now, should this situation ever arise again. The only thing we can do here is learn and do better in the future. - Christian
may boost should look at the way the build tree is managed, on a way something like that (using 'asio' as a examble, but could be 'spirit' and all others) ... ex: boost_root git tree src edge spirit (submodule from 'boost_spirit' repo, point to 'develop' branch or something like that) asio (submodule from 'boost_asio' repo, point to 'develop' branch or something like that) stable spirit (submodule from 'boost_spirit' repo, point to latest 'stable' (and compatible with boost) branch or something like that) asio (submodule from 'boost_asio' repo, point to latest 'stable' (and compatible with boost) branch or something like that) then authors (and/or boost release mantainers?) update 'stable' branch references with latest stable and tested libraries for release... the boost build process could create more targets with something like 'source=stable' (as default) and have a option 'source=edge' (or some other name). also could be by 'library', as 'source=stable specific_source=spirit/edge'... (to help testing with specific edge libraries) i don't know if this may not be a good way of handling this situation, but serves as inspiration for creating something to take care of boost development and releases, and author doing all the work on external libraries the way they want, while trying to keeping some things stabilized On Fri, Sep 12, 2025 at 12:12 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
On Thu, Sep 11, 2025 at 6:05 PM Joel de Guzman via Boost < boost@lists.boost.org> wrote:
That being said, I urge the Boost community to maintain a kind and welcoming tone. That was not the case in the message that started this thread. Maintaining a library is NOT a trivial task, everyone knows that, and it is disheartening to see maintainers leave because of the toxicity. Here's one from @Kolejey from May 8:
"The main reason I've stopped working on improvements is because I got yelled pretty much every time I fix a bug or change some internal stuff that no one should've relied on. And I get their viewpoint, Boost nowadays is seen as a collection of mostly legacy battle- tested libraries, a project uses Boost because it have used it for a long while and people that maintain it don't want their working code been disturbed."
And this reflects the scenario we have now, again.
Indeed.
As a community, we failed here. And I'm including myself in this as well.
We were so quick to get riled up and argue and bicker with each other, that we missed the obvious solutions and steps.
We should've simply shown the new maintainer how to use boostdep, how to do regression testing across the list of reported libraries and then instructed them on how we roll out large deprecating changes, similar to the C++03 deprecation.
We could've avoided a lot of pain and drama.
Alas, the cost of wisdom is foolishness and at the very least, I know what to do in the future now, should this situation ever arise again.
The only thing we can do here is learn and do better in the future.
- Christian _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/4Q7HA4TK...
Joel de Guzman wrote:
Due to some backlash with this PR, mostly due to breaking changes. We should probably ease up and rethink what we are doing here. Boost thrives on consensus, and the discussions seem to be going in a negative direction, which should be addressed both in the PR and in this mailing list.
I urge the parties to raise the issues the the PR:
https://github.com/boostorg/spirit/pull/807
FWIW, my position is that I am all for modernizing and moving to C++23, but it should be done carefully and with consideration to users of Spirit X3 and Boost in general.
I think that we should give serious consideration to the idea of rolling back X3 to its previous C++17 state and instead making a separate "version 4" Spirit that is C++23 and where new development can be focused. As Alexander points out in the issue, this will also make the boostorg/spirit split unnecessary (although we can still go ahead with it if we decide it's a good idea for other reasons.) This way people who can't move past C++17 for various reasons (such as the MQTT5 users) can still continue using X3.
On 9/12/25 7:13 AM, Peter Dimov via Boost wrote:
Joel de Guzman wrote:
Due to some backlash with this PR, mostly due to breaking changes. We should probably ease up and rethink what we are doing here. Boost thrives on consensus, and the discussions seem to be going in a negative direction, which should be addressed both in the PR and in this mailing list.
I urge the parties to raise the issues the the PR:
https://github.com/boostorg/spirit/pull/807
FWIW, my position is that I am all for modernizing and moving to C++23, but it should be done carefully and with consideration to users of Spirit X3 and Boost in general. I think that we should give serious consideration to the idea of rolling back X3 to its previous C++17 state and instead making a separate "version 4" Spirit that is C++23 and where new development can be focused.
As Alexander points out in the issue, this will also make the boostorg/spirit split unnecessary (although we can still go ahead with it if we decide it's a good idea for other reasons.)
This way people who can't move past C++17 for various reasons (such as the MQTT5 users) can still continue using X3.
I concur. This is the right way to go. Nana Sakisaka, is that a direction you'd be interested to pursue? This is the safest path forward. Regards, -- Joel de Guzman Cycfi Research, Inc.
2025年9月12日(金) 9:35 Joel de Guzman via Boost <boost@lists.boost.org>:
On 9/12/25 7:13 AM, Peter Dimov via Boost wrote:
I think that we should give serious consideration to the idea of rolling back X3 to its previous C++17 state and instead making a separate "version 4" Spirit that is C++23 and where new development can be focused.
As Alexander points out in the issue, this will also make the boostorg/spirit split unnecessary (although we can still go ahead with it if we decide it's a good idea for other reasons.)
This way people who can't move past C++17 for various reasons (such as the MQTT5 users) can still continue using X3.
I concur. This is the right way to go. Nana Sakisaka, is that a direction you'd be interested to pursue? This is the safest path forward.
As a Spirit maintainer, I've decided it is time to start Spirit.X4. I believe the name "Spirit.X4" is the right choice because it reflects the spirit of Spirit, as Joel mentioned here: https://github.com/boostorg/spirit/pull/807#issuecomment-3282965760 After the migration is complete, I plan to return the existing `boostorg/spirit` codebase to a C++17 baseline, as Peter suggested. ---------------------------------------------------------- Request to core members: - Please create a new repository, `boostorg/spirit_x4`, and grant permissions to my account, @saki7. - I'm requesting full (admin) access for the new repo, if that's possible. I currently have only "Collaborator" access on `boostorg/spirit`, which has prevented me from adding some features to CI. Furthermore, I'd prefer full control on the new repo to experiment with GitHub features proactively. - If it isn't feasible, please grant at least permissions to: - "Environments" tab - "Deploy keys" tab - "GitHub Apps" tab - The access to "Environments" tab is required for the "deploy" feature of GHA. It is required to host the temporary preview of AsciiDoc contributions per pull-request scope. This request is based on my personal experimentation, where I found the outside collaborators cannot push directly to the "GitHub Pages", thus it is impossible to host a fully featured preview site on pull-request scope. - I'm planning to add some local bot that alerts compiler warnings in our CI. I need "Deploy keys" and "GitHub Apps" for that. ---------------------------------------------------------- On a personal note, I'm both technically and emotionally satisfied with this direction. Launching Spirit.X4 will let us safely deprecate obsolete features. I'll start by revising the README to document X4's deprecation policy, minimum supported toolchains, and related details. Thank you to everyone involved in the discussion. The encouragement from core devs reinforces my impression that Boost is moving in a constructive and inclusive direction.
Nana Sakisaka wrote:
As a Spirit maintainer, I've decided it is time to start Spirit.X4.
I believe the name "Spirit.X4" is the right choice because it reflects the spirit of Spirit, as Joel mentioned here: https://github.com/boostorg/spirit/pull/807#issuecomment-3282965760
After the migration is complete, I plan to return the existing `boostorg/spirit` codebase to a C++17 baseline, as Peter suggested.
----------------------------------------------------------
Request to core members:
- Please create a new repository, `boostorg/spirit_x4`, and grant permissions to my account, @saki7.
Done. Let me know when it's ready to be added as a submodule to the boostorg/boost superproject.
2025年9月13日(土) 8:22 Peter Dimov via Boost <boost@lists.boost.org>:
Request to core members:
- Please create a new repository, `boostorg/spirit_x4`, and grant permissions to my account, @saki7.
Done. Let me know when it's ready to be added as a submodule to the boostorg/boost superproject.
Thank you. I just merged a PR on the old repository, which reverts all the C++23 PRs. The `develop` branch of `boostorg/spirit` is back to the old state and works on C++17, effective immediately. It would require a decent amount of time to prepare `Spirit.X4`. After the work is complete, I'll post a message.
pt., 12 wrz 2025 o 01:16 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
Joel de Guzman wrote:
Due to some backlash with this PR, mostly due to breaking changes. We should probably ease up and rethink what we are doing here. Boost thrives on consensus, and the discussions seem to be going in a negative direction, which should be addressed both in the PR and in this mailing list.
I urge the parties to raise the issues the the PR:
https://github.com/boostorg/spirit/pull/807
FWIW, my position is that I am all for modernizing and moving to C++23, but it should be done carefully and with consideration to users of Spirit X3 and Boost in general.
I think that we should give serious consideration to the idea of rolling back X3 to its previous C++17 state and instead making a separate "version 4" Spirit that is C++23 and where new development can be focused.
As Alexander points out in the issue, this will also make the boostorg/spirit split unnecessary (although we can still go ahead with it if we decide it's a good idea for other reasons.)
This way people who can't move past C++17 for various reasons (such as the MQTT5 users) can still continue using X3.
And, given that we now also have Boost.Parser, it will make the question "which Boost Parsing library I should use" even more difficult for the new users. Regards, &rzej;
On Sat, Sep 13, 2025 at 12:14 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
it will make the question "which Boost Parsing library I should use" even more difficult
To keep things interesting, Boost.URL has its own parsing sublibrary called Grammar: https://github.com/boostorg/url/tree/develop/include/boost/url/grammar https://www.boost.org/doc/libs/master/doc/antora/url/grammar/index.html Thanks
On Thu, Sep 11, 2025 at 10:40 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:
Christian Mazakas wrote:
Right now the only people mad about the X3 change are just Boost authors.
That's because rest of world hasn't yet had the pleasure of experiencing it.
Right. But, being honest, I think X3 was considered largely abandoned for a good chunk of time, with only basic maintenance being done. I think Joel's operating assumption is that handing off the library and bumping the minimum version to 23 is fine because no one was really using it. A big part of the value-add of Parser at the time was that it was an actively maintained parser combinator library. What's more, it's not like users are going to be suffering because of this. It just means they can't upgrade Boost for projects where they can't upgrade their minimum supported toolchain. Not being able to upgrade Boost does not cause massive reputational damage to the project because it's not uncommon for Boost libraries to introduce expensive API breaks regardless. I think there's a lot of hyperbole going on here and we're being unfair to a new contributor who wants to actually push the envelope. The MQTT authors have even said they can just roll with switching to Parser and getting the changes in time for the next release so as far as I can see, this is much ado about nothing. - Christian
participants (14)
-
Alexander Grund -
Andrey Semashev -
Andrzej Krzemienski -
Arnaud Becheler -
Christian Mazakas -
Dominique Devienne -
Jean-Louis Leroy -
Joel de Guzman -
Matt Gruenke -
Nana Sakisaka -
Peter Dimov -
Seth -
Vinnie Falco -
Virgilio Fornazin