# Could a dyn type have more traits?

**URL:** <https://internals.rust-lang.org/t/could-a-dyn-type-have-more-traits/20689>\
**Category:** language design\
**Created:** [April 21, 2024, 7:06am UTC](https://internals.rust-lang.org/t/could-a-dyn-type-have-more-traits/20689 "2024-04-21T07:06:55Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![SkiFire13](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/skifire13/32/7579_2.png) [@SkiFire13](https://internals.rust-lang.org/u/SkiFire13)\
**Post date:** [April 21, 2024, 9:31am UTC](https://internals.rust-lang.org/t/could-a-dyn-type-have-more-traits/20689/3 "2024-04-21T09:31:13Z")

</div>

Just allowing `dyn Trait1 + Trait2` has its own implementation problems (see for example [Where's the catch with Box\<Read + Write\>?](https://internals.rust-lang.org/t/wheres-the-catch-with-box-read-write/6617) and [Sieve-tables for multiple traits objects (Box\<A+B+C\> to Box\<A+C\>, #2035)](https://internals.rust-lang.org/t/sieve-tables-for-multiple-traits-objects-box-a-b-c-to-box-a-c-2035/15397)) except when the additional traits are autotraits, e.g. `Send` or `Sync`, for which this is already possible.

The alternative for now is to create a new trait with all the bounds with a blanked implementation. So instead of `Box<dyn Trait1 + Trait2>` you would have `Box<dyn CombinedTrait>` where `CombinedTrait` is defined as follows:

```rust
trait CombinedTrait : Trait1 + Trait2 {}
impl<T: Trait1 + Trait2 + ?Sized> CombinedTrait for T {}

```

Even then though it wouldn't work for your particular case because neither `Hash` nor `Eq` are [object safe traits](https://doc.rust-lang.org/reference/items/traits.html#object-safety). For `Hash` this is because it contains generic functions, which correspond to infinite concrete functions, so they cannot be included in the trait object vtable. For `Eq` this is because types implementing it expect to only ever be compared with other instances of the same type, but with `dyn Eq` you could compare a type with a completly different one.

I don't think they will ever become object safe (maybe `Hash`, but definitely not `Eq`), so you have to solve this manually. @quinedot already showed how make object-safe variants of them so that you can implement `Hash` and `Eq` for `dyn YourTrait`, and that's the correct solution:

> [@quinedot](#):
>
> you could [use `dyn Any` as a supertrait bound to enable downcasting and make `dyn Obverser` comparable for equality,](https://quinedot.github.io/rust-learning/dyn-trait-eq.html) and also [hashable.](https://quinedot.github.io/rust-learning/dyn-trait-hash.html)

> [@Jnternet](#):
>
> but i can't impl those trait for Box

You should implement them for `dyn YourTrait` because it's a local type in your crate, then `Box` will automatically implement them whent he inner type implements them.

---

_[View the full topic](https://internals.rust-lang.org/t/could-a-dyn-type-have-more-traits/20689)._