Pre-RFC: Sealed traits

[durka]

http://is.gd/yqIPc5

Heh, didn’t know about that trick. And TBH I would have expected a “private type in public interface” error when exporting f(). Like I said it’s really hard to know whether these holes in the checker are intentional or not.

[nikomatsakis]

The rule is actually very simple: are you write a signature of something declared as public? If so, then the things it refers to must be declared as public. (It doesn’t matter if they are “accessible” in any grander sense, it’s all about how they are declared.)

I don’t see this as a “hole” in privacy: it’s about what your goals are. The goal here is to ensure that if something is declared as priv, you only need to look within the current module (and its submodules) to know who has access to it. If it is declared as pub, you have to work harder, because you have to care about how things are exported or re-exported. I’d prefer more expressive pub declarations, like in https://github.com/rust-lang/rfcs/pull/1422, which would mean that we can extend “private” out to enclosing modules, and not just enjoy its benefits within the current module.

Anyway, this is afield from this thread…

[durka]

Right, but apparently a trait bound on a parameter doesn’t count as “referring”. Previously you could do a private supertrait, which is just a kind of implicit where-clause, i.e. a trait bound, but that was somehow different… maybe you can see how this is somewhat subtle and confusing to an outsider

Sorry for going off-topic. To come back, it seems (partly evidenced by these workarounds) that there is a need for sealed-trait functionality.

Personally, I feel that having #[sealed] affect traits like Send is “too much magic” or complicates the rules too much. If I understand right, the rule could be "if Trait is sealed and all implementors are Send, then Box<Trait> is the same as Box<Trait + Send>"? But then the Send-ness can be lost even by adding another impl. Maybe this case could be covered by allowing unsafe impl Send for Trait {}.

[Popog]

Another potential use case for #[sealed] (in conjunction with specialization) is type traits:

#[sealed]
trait RemoveIndirection {
    type Type: ?Sized;
}

impl<T: ?Sized> RemoveIndirection for T {
    default type Type = T;
}
impl<'a, T: ?Sized> RemoveIndirection for &'a T {
    type Type = <T as RemoveIndirection>::Type;
}
impl<T: ?Sized> RemoveIndirection for *const T {
    type Type = <T as RemoveIndirection>::Type;
}

[TheDan64]

Is there any update to this / was there ever a RFC released? I’ve run into the situation @nikomatsakis described to a T:

I’m writing a FFI safe wrapper and have created a bunch of newtypes over raw pointers. I’ve also created trait(s) that acts as sets, allowing a subset of these newtypes to work for a given function.

The trait(s) need to be public, so that users can supply generated objects to methods, but it would likely be disastrous if they decided it would be a good idea to implement their own objects for the traits.

For my use case, sealing the traits sounds like a good solution.

Related question: would it be permissible to leak a public super trait’s private sub traits if the super trait is #[sealed]? Since users aren’t allowed to implement the trait anyway…

[sfackler]

The standard convention right now is something like this:

pub trait MyThing: Sealed {
    // ...
}

mod private {
    pub trait Sealed {}
}

[cbreeden]

Can you do this now?

pub(crate) trait Sealed { }

[petrochenkov]

With https://github.com/rust-lang/rfcs/pull/2028 something like this will be available as well:

pub trait MyThing {
    fn public_method(&self);

    pub(self) fn private_method_that_cannot_be_implemented_outside_of_this_module_making_the_trait_sealed();
}

[jethrogb]

Unfortunately, no: https://is.gd/wfpcIp

[glaebhoerl]

Isn’t unsafe trait (also) an appropriate solution to this?

[TheDan64]

pub trait MyThing: Sealed { // … }

mod private { pub trait Sealed {} }

Despite the fact that it seems like a hack or bug and not an actual language feature I guess I would choose this if I absolutely don’t want anyone implementing my trait and/or I have private methods/objects I also don’t want to expose (defined/implemented on Sealed).

Isn’t unsafe trait (also) an appropriate solution to this?

The way I understand unsafe trait is that it can still be implemented by API users, but at least it requires an unsafe opt in. Would also potentially expose methods/objects that I might only want to be private. So it’s not an exact drop-in replacement for #[sealed]

[cuviper]

Using unsafe makes it more like a social contract than a compiler-enforced one.

[vi0]

Using unsafe as a makeshift sealed traits feature also dilutes the “here be Segmentation Fault” meaning of unsafe by provoking creation of perfeclty safe (with respect of memory safety) crates that do nonetheless contain The Dreaded Unutterable unsafe (and can’t work under #[forbid(unsafe_code)] and don’t get hypothetical “I’m unsafe-free” crates.io badge ).

[glaebhoerl]

(I was responding specifically to @TheDan64’s use case. The whole point there is that downstream crates shouldn’t declare any unsafe impls because it would be memory-unsafe. I appreciate that sealed traits would be even more airtight, but the specific problems you cite don’t really apply.)

[Ekleog]

Something for which compiler support for sealed traits would be highly useful would be non-public methods in sealed traits.

For instance, I currently want to have a marker trait used in my library that’s used to restrict generic functions to some traits from my library. But these generic impls must now depend only on the interface of the marker trait, which means it has to export enough functions to be usable from said generic functions. And so these functions become part of the public API.

In code, here is what I’d like:

#[sealed]
trait Trait {
    pub(crate) fn foo(&self);
}

struct Struct {}
impl Trait for Struct { fn foo(&self) {} }

fn bar<T: Trait>(t: &T) { t.foo() }

Does what I’m hoping for make sense? Currently the best way to do it appears to be #[doc(hidden)]… or defining a private struct in my library and taking it as an argument.

I don’t see any way other than sealed traits to do this cleanly, as pub(crate) would make no sense for non-sealed traits.

[jjpe]

@Ekleog have no hard opinions on #[sealed], but as I understand it trait methods are currently always public no matter what, so the pub(crate) for method foo would require a further language change at the very least.

[Yato]

I think another thing to note is that sealed traits allow for a more gradual shift from enums to traits and vice versa.

	Extendable from outside	Can be used as Constraints
enum	No	No
sealed traits	No	Yes
traits	Yes	Yes

It seems like the perfect fit for something between enums and traits.

---

On this note, trait objects of sealed traits don’t need to store a vtable and perform dynamic dispatch, they could just store an index which specifies which type they are and use that to figure out which impl to call, thus making them effectively as fast as enums, while still being a trait!

---

~edit~

Also on the note of using indices to differentiate types, this could be used to provide a way to downcast references into their concrete types for all sealed traits.

---

~edit 2~

Indexes cannot be used in general due to how amazing generics are.

[CAD97]

FWIW, Kotlin sealed classes are basically this approach to sealed traits, though also being the “data carrying enumerated type” and using the JVMs casting support still.

I wonder if a proc macro could be written to implement this in user code… it would also basically be equivalent to “enum variants are types” while the restriction of implementors being in the same file (macro block) holds.

(I do not have time and should not implement this but)

sketch

#[enum_trait]
pub trait Example {
    Case1(String),
    Case2 {
        alpha: usize,
        beta: isize,
    }
}

// translates to

mod $unnamable {
    pub trait Sealed {}
}

pub trait Example: $unnamable::Sealed {}
pub enum dynExample {
    Case1(Case1),
    Case2(Case2),
}

pub struct Case1(pub String);
pub struct Case2 {
    pub alpha: usize,
    pub beta: isize,
}

impl Example for Case1 {}
impl Example for Case2 {}

// plus handle conversions via (Try)Into
// and other derives as well

But having written that, I like the idea of having sealed traits’ vtable instead be an index, so dyn SealedTrait is just the regular struct and the fat pointer has the enum discriminant.

The comparison to “enum variants as types” stands, though.

[Yato]

enum variants as types

That was exactly what i was thinking of, just couldn’t remember the phrase.

I love that this could be the bridge between enums and traits.

[Yato]

Another thing we could guarantee about the sealed traits is that dyn Trait: Sized where Trait is a sealed trait and that dyn Trait is laid out exactly the same as an enum with each variant of the enum hold exactly one of the types. This could be huge as it will enable ergonomic error handling. This doesn’t dilute the meaning of dyn, it still means dynamically dispatched, it just changes how it is dispatched. Also with this, sealed traits can be object safe even if they have consuming functions (i.e. functions that take self). no we can’t, generics don’t allow it.

ignore rest of this post

For example (simple example)

trait CustomError {  }

struct DivByZero;
struct SqrtOfNegativeNumber;

impl CustomError for DivByZero {}
impl CustomError for SqrtOfNegativeNumber {}

fn fallible(x: f32) -> Result<f32, dyn CustomError> { // note: dyn CustomError would be Sized
    if x > 0.0 {
        Ok(1.0 / x.sqrt())
    } else if x == 0.0 {
        Err(DivByZero)
    } else {
        Err(SqrtOfNegativeNumber)
    }
}

And this could just work! It is easily extensible and the users of this code can just use the interface provided by the trait (this is a lot like how Pre-RFC: sum-enums works, but more useful).