Pre-RFC: Sealed traits

[glaebhoerl]

As I commented on the “no private items in public interfaces” RFC at the time, by analogy with structs, the way to express sealed traits that feels “right” to me would be to allow traits to have private associated items (whether we re-introduce the priv keyword for this, or whatever). A trait can be thought of as just a struct type containing fns and so on with extra compiler magic to pass it around and access its members implicitly, with impl fors being the only way to construct instances of it, so just like a private field in a struct means only the owning module can construct one, a private method or other associated item in a trait would mean only the owning module can impl it.

[nikomatsakis]

Well, it’s always possible to declare a public trait – and thus one hypothetically exposed to the world – but “seal it off” through an inaccessible path http://is.gd/yqIPc5, no? (I didn’t look at your example in great detail, perhaps there is some other wrinkle I’m missing)

(By the way, this is a lousy way to “seal” a trait, since it means that nobody can wrap your generic function with a generic function of their own, since they can’t name the traits in your where clauses.)

[sgrif]

I think this is not quite correct. I think the concern is that somebody could implement the trait FromSql, not FromSqlRow (this may just have been a typo on your part)

Yes, that was a typo. Apologies.

[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.