### Author:  [@CAD97](https://internals.rust-lang.org/u/CAD97)
#### Post date: [July 8, 2020, 7:14pm UTC](https://internals.rust-lang.org/t/pre-rfc-expand-object-safety/12693/2 "2020-07-08T19:14:10Z")
> [@PoignardAzur](#):
>
> - If the `?dyn` qualifier isn't used, the current rules apply.
> - If the `?dyn` qualifer is used, `my_func` is only allowed to use the dyn-safe subset of MyTrait.
My one largest fear is that makes the concept of a "completely dyn-compatible trait" more subtly problematic. Because now instead of `dyn Trait` being an error for traits that aren't, whether `fn foo(impl Trait); foo(&x as &dyn Trait)` works is not based on whether `dyn Trait` works but on whether `Trait` is "completely dyn-compatible". (Or otherwise stated, whether adding `?dyn` is a no-op.)
My secondary fear is smaller, but that basically every generic argument is going to be `?dyn`. As the set of things allowed under `?dyn` grows, the reason to _not_ use `?dyn` shrinks, so it will eventually end up just a required sigil for most use cases (that can still be omitted and then just make the API less usable).
But this is also effectively what best practices are today, just that you separate out the dyn-safe part of the trait manually. For that reason I think this is probably an improvement and motion in the correct direction, and I fail to see an edition-compatible way to make the default not be "wrong." (Except _maybe_ ``, but that also seems strictly worse.)
---
### Author:  [@Manishearth](https://internals.rust-lang.org/u/Manishearth)
#### Post date: [September 19, 2020, 6:23pm UTC](https://internals.rust-lang.org/t/pre-rfc-expand-object-safety/12693/3 "2020-09-19T18:23:54Z")
> [@PoignardAzur](#):
>
> For each trait, internally compute a dyn-safe subset of that trait. For instance, that subset would exclude associated functions and associated constants.
So, a lot of people aren't aware of this, but you can make this work manually already, you can "opt out" of associated items being included on trait objects with `where Self: Sized`. I personally vastly prefer this: object safety rules are typically not on the forefront of my mind so when reading code it is easier if I can see that an associated item doesn't work on the trait object instead of having to check if something is object safe. And I _wrote_ the docs on the different reasons a method may not be object safe.
Furthermore, note that this is infectuous: any method returning an associated item, any method _using_ an associated item in its defaulted body, all need to have `where Self: Sized` as well, which means the reason why a method is inaccessible on a trait object may not be immediately obvious.
Every time I've had to make a trait object safe, there has been a cascade of changes (usually `where Self: Sized`s) that is necessary to make it work. It is hard for me to see how these changes can be implicitly made by the compiler in all but the simplest case, and it's hard for me to see how implicit `where Self: Sized` will not be confusing for people.
> [@PoignardAzur](#):
>
> Add a `?dyn` trait qualifier to template parameters. Possible syntax:
I do not see how this is any different from `T: ?Sized + MyTrait`. You mention later that not mentioning `Sized` is deliberate, but I don't see the point of `?dyn` here aside from perhaps distinguishing object safety issues from unsized type issues.
Furthermore, `?dyn` as a term is confusing: `?Sized` means "may not be Sized (the default)", whereas `?dyn` means "may be `dyn` (not the default)". The `?` means different things here.
> [@PoignardAzur](#):
>
> Allow trait objects to have generic methods and be dyn-safe, _if_ every generic type argument is bound to a dyn-safe trait or the dyn-safe subset of a trait. Example:
The reason generic methods are not object safe is not because of the trait bounds being not-object safe, it is because it can explode the vtable -- you now need a vtable entry for each debuggable type in your program.
---
### Author:  [@PoignardAzur](https://internals.rust-lang.org/u/PoignardAzur)
#### Post date: [October 9, 2020, 9:38pm UTC](https://internals.rust-lang.org/t/pre-rfc-expand-object-safety/12693/4 "2020-10-09T21:38:17Z")
Late reply:
> [@CAD97](#):
>
> My secondary fear is smaller, but that basically every generic argument is going to be `?dyn` . As the set of things allowed under `?dyn` grows, the reason to _not_ use `?dyn` shrinks, so it will eventually end up just a required sigil for most use cases (that can still be omitted and then just make the API less usable).
That's the plan, really. Ideally we'd get to a point where `?dyn` is the default and non-dyn-compatible generics are the exception that require an annotation. (with the benefits in dynamic linking, compile times, etc, this entails)
> [@Manishearth](#):
>
> So, a lot of people aren't aware of this, but you can make this work manually already, you can "opt out" of associated items being included on trait objects with `where Self: Sized` .
My understanding is that you can't put this bond on associated consts, though.
But yeah, I did some tests in the playground and that workaround is more powerful than I thought.
> [@Manishearth](#):
>
> The reason generic methods are not object safe is not because of the trait bounds being not-object safe, it is because it can explode the vtable -- you now need a vtable entry for each debuggable type in your program.
In this case, a single vtable entry would be generated, that would itself use the `std::fmt::Debug` vtable of the passed object.
The vtable would essentially be used similarly to Swift's witness tables.
---
### Author:  [@Manishearth](https://internals.rust-lang.org/u/Manishearth)
#### Post date: [October 9, 2020, 11:23pm UTC](https://internals.rust-lang.org/t/pre-rfc-expand-object-safety/12693/5 "2020-10-09T23:23:04Z")
> [@PoignardAzur](#):
>
> My understanding is that you can't put this bond on associated consts, though.
That seems to me to be the stronger fix for most of the use cases of this RFC.
> [@PoignardAzur](#):
>
> In this case, a single vtable entry would be generated, that would itself use the `std::fmt::Debug` vtable of the passed object.
That's going to force a `?Sized` on those as well, it's going to be infectuous. Also, this cannot handle _multiple_ generics that mix particularly well.
---
### Author:  [@system](https://internals.rust-lang.org/u/system)
#### Post date: [January 7, 2021, 11:23pm UTC](https://internals.rust-lang.org/t/pre-rfc-expand-object-safety/12693/6 "2021-01-07T23:23:35Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.