Post #3741395

2026-07-11 01:41 UTC

RE: https://hachyderm.io/@chandlerc/116734192778208742 We have a recording available of this **early** preview now!! Video: https://drive.google.com/file/d/1tQlzpnbWZfn2WtTFMoJgF93QteByBBwm/view?usp=sharing Slides: https://chandlerc.blog/slides/2026-memory-safety-deep-3/ Transcript: https://docs.google.com/document/d/1JB9H3KzVixAPC5WIytS4AMyrvjwzC7TXqp596veLT34/edit?usp=sharing See my post below for some big caveats -- this is just the very first, rough description of the model we're looking at. We still have lots to do to write it all up in a cohesive document, go through the exercise of fully mapping it onto a real set of standard library APIs, and of course, implementing it which is a huge future item of work. But if you're interested in a peak at where we're going and like early-stage PL design, take a look! PS: sorry I didn't post more updates about the live version, but thanks everyone who joined! The recording isn't the live version, just Josh presenting it, but it benefitted from the live presentation, all the questions asked, and all the feedback we've already received.

Replies (1)

@Gankra@toot.cat 2026-07-11 02:26

@chandlerc@hachyderm.io Only skimmed the slides for now but this feels like it will be brutal to write interfaces for, which unfortunately makes sense if you’re trying to faithfully encode typical c++ interfaces. Y’all have clearly done a lot more homework on this problem at this point than probably anyone, which makes me excited to see where you find the serious friction in this design. As a collections API person my assumption has always been that C++-style iterators (and slices) will be the most painful things to describe and abstract over in any system like this. As an unsafe rust person, I am also worried about the complexity and stakes of writing the signatures of the safe api over the unsafe code — we had a lot of mishaps in rust land back in the day from bad defaults or the compiler not applying some conservative assumption the api author has to opt out of. As a gradual types person I am excited to see where your non-strict mode is forced to make unsound assumptions for the sake of common case ergonomics and usability (no one is without sin here, especially once inheritance is involved!)

Open ##4333759