Hi. I am proud to announce that the C++ Alliance has entered into a partnership with Sean Baxter to develop Safe C++: language extensions to provide memory safety in C++. Some of you might have seen the official announcements on various social media sites, and I’m here to provide some more information on how this initiative affects Boost. First, I want to express my appreciation for Sean’s enormous technical abilities, and for his stamina to invest eight years of research and development into Safe C++. I believe that his efforts reflect good philosophical principles for improving the language with memory safety extensions: 1. Safe C++ must be a superset of C++: all existing code must work. 2. Safe C++ must allow controlled opt-in to memory safety: expecting the world to rewrite everything in a new language is not realistic. 3. Safe C++ must be developed using an implementation-first approach: a working model is preferable to just ideas. The partnership with Alliance has three deliverables: research the remaining design problems, complete the Safe C++ Language Extensions proposal for standardization, and implement the Safe C++ Standard Library. The safe library is a set of additions to the standard library providing essential vocabulary types and algorithms needed by users to achieve memory safety. We don’t know that Safe C++ is the final solution for memory safety in C++. Perhaps the required extensions will be so intrusive as to make it effectively a new language. Maybe the language features which allow for zero-cost abstractions are so powerful that they can’t be preserved in ways that are memory safe. Yet there is value in pioneering this design space that Sean has carved out. It is also possible that Safe C++ becomes the winning memory safety story for C++. We at the Alliance believe it is worth taking the chance to find out. Through the relationship with Alliance, the Boost community has a unique opportunity to participate in helping to explore and solve the remaining difficult design problems, and a front-row seat to the latest draft of the Safe C++ proposal which can be viewed here: https://safecpp.org/draft.html If you would like to discuss Safe C++ in real time with other engineers please join the #safe-cpp channel in the Official C++ Language Slack Workspace by signing up here: https://cppalliance.org/slack What does this mean for Boost? There is a tremendous opportunity here for Boost to innovate ahead of the C++ Standard. I envision the scenario where some volunteers will port selected Boost libraries to Safe C++ as a proof of concept. The porting process will surface areas of the proposal which need work. As memory safety is rapidly becoming the defining feature of modern mission-critical software development, the opportunity for Boost to lead in this area may attract the needed revitalization of the project in the form of new volunteers. Please join us in helping to define this exciting chapter of the C++ language! Thanks
On Mon, Sep 16, 2024 at 5:36 PM Vinnie Falco via Boost
Hi. I am proud to announce that the C++ Alliance has entered into a partnership with Sean Baxter to develop Safe C++: language extensions to provide memory safety in C++.
Hi. How is that related to his Circle compiler? And does that mean [Circle might finally be available on Windows][1]? Or Safe C++ and Circle are completely unrelated? --DD [1]: https://github.com/seanbaxter/circle/issues/20
On Mon, Sep 16, 2024 at 9:06 AM Dominique Devienne
Hi. How is that related to his Circle compiler?
Safe C++ is a standards proposal which adds extensions to the C++ language for implementing memory safety. Circle is a compiler which implements the Safe C++ Extensions.
And does that mean [Circle might finally be available on Windows][1]?
The work required for a complete Safe C++ extensions proposal is significant. For now the focus of development is on memory safety and completing the proposal.
Or Safe C++ and Circle are completely unrelated?
Safe C++ is an open specification of extensions to the C++ language to enable memory safety, while Circle is a compiler used to perform research in developing the Safe C++ specification. Thanks for your interest!
On Mon, 16 Sep 2024, 17:37 Vinnie Falco via Boost,
What does this mean for Boost?
There is a tremendous opportunity here for Boost to innovate ahead of the C++ Standard. I envision the scenario where some volunteers will port selected Boost libraries to Safe C++ as a proof of concept. The porting process will surface areas of the proposal which need work. As memory safety is rapidly becoming the defining feature of modern mission-critical software development, the opportunity for Boost to lead in this area may attract the needed revitalization of the project in the form of new volunteers.
This is really exciting. I'm up for porting my library (or help port its dependencies).
On Mon, Sep 16, 2024 at 9:25 PM Ruben Perez
This is really exciting. I'm up for porting my library (or help port its dependencies).
I love the enthusiasm but Asio has 1,537 dependencies, give or take.... we need to set our sights a bit lower :) Boost.Config, Assert, or throw_exception come to mind. Then maybe something small like StaticString although that one might already be mostly safe. Boost.SmartPtr perhaps? We would need to talk to the Safe C++ folks. Thanks
On Tue, 17 Sept 2024 at 07:37, Vinnie Falco
On Mon, Sep 16, 2024 at 9:25 PM Ruben Perez
wrote: This is really exciting. I'm up for porting my library (or help port its dependencies).
I love the enthusiasm but Asio has 1,537 dependencies, give or take.... we need to set our sights a bit lower :)
Boost.Config, Assert, or throw_exception come to mind. Then maybe something small like StaticString although that one might already be mostly safe. Boost.SmartPtr perhaps? We would need to talk to the Safe C++ folks.
Thanks
That's why I said dependencies :) I suspect that most of SmartPtr is covered by the classes std2::box and std2::rc, which AFAIK are the Rust safe equivalents of unique_ptr and shared_ptr. Do you envision Boost as a place to host an implementation of the std2 library? Or rather as a "test ground" where libraries (say charconv or json) actually use such standard facilities? (or both?) Anyway, I'm on the slack channel now too. Thanks, Ruben.
On Mon, Sep 16, 2024 at 10:38 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:
I love the enthusiasm but Asio has 1,537 dependencies, give or take.... we need to set our sights a bit lower :)
To be fair, Niall and I already discussed that it's relatively straightforward to just reimplement Asio. Because Safe C++ is a post-C++20 world, it makes more sense to simply just rewrite Asio and only code it against coroutines. The universal async model was a cool idea at the time but didn't catch on like we would've hoped. I've actually implemented safe networking in Rust, it's easy for me to implement it in Safe C++ as well. - Christian
On Tue, Sep 17, 2024 at 5:23 PM Christian Mazakas via Boost
On Mon, Sep 16, 2024 at 10:38 PM Vinnie Falco via Boost < To be fair, Niall and I already discussed that it's relatively straightforward to just reimplement Asio.
Because Safe C++ is a post-C++20 world, it makes more sense to simply just rewrite Asio and only code it against coroutines.
Except Circle does not support coroutines. Sean mentions it during the Q&A of [his presentation to the commitee][1], at the end. That's a few months old though, so maybe that has changed? Vinnie, how to get updates on Safe C++ and its Circle implementation? [1]: https://www.reddit.com/r/cpp/comments/1cnqlqi/safe_c_sean_baxter_presenting_...
On 9/16/24 10:37 PM, Vinnie Falco via Boost wrote:
On Mon, Sep 16, 2024 at 9:25 PM Ruben Perez
wrote: This is really exciting. I'm up for porting my library (or help port its dependencies).
I love the enthusiasm but Asio has 1,537 dependencies, give or take.... we need to set our sights a bit lower :)
How can there be 1537 dependencies on \~160 boost libraries?
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (5)
-
Christian Mazakas
-
Dominique Devienne
-
Robert Ramey
-
Ruben Perez
-
Vinnie Falco