Post #4333762

2026-07-11 04:11 UTC

@Gankra@toot.cat First off, awesome thoughts just from the slide skim -- super happy to have this kind of feedback. Regarding writing interfaces -- that's definitely something we're thinking about. Are there specific examples off the top of your head that seem worrisome here? If so, super useful to know, and we can probably work some examples with them to see how it plays out. FWIW, the interfaces we've sketched so far look OK -- not as simple as Rust, but that was never an option. But they seem to be progressive in pulling in complexity, and provide a meaningful generic semantic model. That said, one of our next efforts specifically to build some of the primitives of the standard library in the model, as well as some of the canonical layers on top to evaluate. As I said, if you have thoughts of what might be interesting or hard, happy to try and include them in these. And if they surface problems, we can still change this easily. =] Regarding iterators (and slices) -- the whole system is designed to allow all of these to be abstract in the same way as pointers, and in a consistent way across all three. But definitely, this is going to be a critical thing to see how it plays out. Regarding unsafe code -- our plan is specifically to _not_ allow optimizing based on safety assumptions. That gives up some optimizations, but we largely don't have them in C++ today (what safety assumptions...), and so we think we can survive. If we need an optimization assumption, we'll add that as a separate and distinct unsafe feature so we can be wildly more cautious about it. So the hope is that the soundness bar for unsafe code is generally much lower (at the price of optimizer not leveraging assumptions). And regarding non-strict mode -- again, the hope is that we can lower the soundness bar to roughly that of C++. Which isn't perfect, but seems like an attainable state and a reasonable tradeoff point. We'll still have to see what it plays out as though. =]

Replies (1)

@Gankra@toot.cat 2026-07-11 05:04

@chandlerc@hachyderm.io the api correctness issues i’m thinking of were never an optimization thing, and were always just “the compiler let code compile that was a blatant use-after-free” (on my phone and going off memory, can elaborate more on any of these if you want more details) * pre-1.0 the rust compiler did not require you to specify the (co/in)variance of a type parameter, and if you declared a type parameter but failed to use it in the definition it actually defaulted to *bivariance* which is literally always incorrect. This resulted in some type like Iter(*const T) basically functioning as if it had no lifetime, oops! This class of bug was eliminated with the introduction of PhantomData (the RFC discusses it). * Rust has obscure support for letting pointers temporary dangle during destructors. You can make a (Box, Vec>) and make one point at the other, and rust won’t complain about the fact that the Vec definitely contains a dangling pointer when its destructor runs. The argument for this being ok is based on Vec’s Drop being parametric (it cannot observe that T is a reference), and this feature is used by rustc devs to do stuff with Arena allocators. “parametric drop” used to be safely inferred by the compiler but it was so buggy and complicated that it was eventually turned into an unsafe opt-in (see the “dropcheck eyepatch” RFC(s)). * The typechecker people have like 1000 war stories around the compiler failing to correctly handle corner cases of the type-erasure stuff you briefly discuss, especially around what lifetimes associated-types should be required to satisfy (not my area of expertese) * The compiler safely infers Send and Sync for ~every type, and the fact that this actually works great in practice is actually shocking to me whenever I think about it, but the secret sauce is that if your type contains *const T, *mut T, or UnsafeCell your type is opted out of this and you must manually unsafe-impl Send and Sync to opt back in (also *mut T makes you invariant in T as a secret bonus controversial safety guard). The fact that we have different types for “normal pointers” and “pointers unsafe code uses” is actually a really important sentinel for forcing the compiler to apply more conservative ~inference. “here there be dragons”. (probably the OIBIT RFC is the source on this)

Open ##4333763