Sealed traits

[Jules-Bertholet]

Prior discussion:

Pre-RFC: Sealed traits

This is an issue that I’ve been wrestling with for a little while, and I think there’s a core way of expressing our APIs that Rust is currently missing. I need to write this up a little bit more in the “RFC” language, and make the examples a bit more abstract, but I wanted to get other people’s opinions on the concept before doing so. (I’m actually unsure if having the motivation be a specific concrete motivation from a real crate is desirable or not here) Proposal: Sealed traits This RFC propo…

[Closed] Pre-RFC: Sealed Traits take 2

This is a brach off of Pre-RFC: Sealed traits, and has few new semantics and lots of new layout guarantees. NOTE This Pre-RFC is CLOSED Sealed Traits Motivation There is a large gap between traits and enums. Traits give you lots of freedom when developing an API, and make it really easy to extend the API to handle types that weren’t handled before, or let users implement it for their own types. Traits can also be dynamically dispatched which is allows for code to handle a variety of types tha…

Dynamic polymorphism – alternative designs discussion

I've actually wanted sealed traits to be a language-level feature for exactly this reason. If a trait is #[sealed] (that is, no one but the declaring crate may write implementations for it), and all of its blanket impls are "sufficiently bound" by sealed traits, it is possible for the compiler to enumerate all types which implement the trait. I feel like this should be an optimization rather than a relaxation of the object-safety rules, though. I believe there has been a separate discussion of …