is illegal
trait Foo {}
```
but it feels too heavyweight (and will break a ton of code), especially if (_totally not given_) we're going to introduce meta traits in the future. Therefore, to me, attributes seem like the cheaper solution right now.
If we go with this `dyn trait Foo {}` syntax, it would also be a breaking change, so we would need to sneak it into edition 2018.
---
### Author:  [@withoutboats](https://internals.rust-lang.org/u/withoutboats)
#### Post date: [March 20, 2018, 11:08pm UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/10 "2018-03-20T23:08:58Z")
> [@Centril](#):
>
> “Dyn capable” just sounds like a shorthand for “Can be used as a dynamic trait type” – not sure why it sounds like jargon to you…?
"Dyn" is short-hand and "X capable" is not really an adjective phrase that I can think of another example of. With "object-safe" at least I have "type-safe" and "memory-safe" to compare it to, which makes it feel less like a technical term I need to memorize. "Capable" is also less of a casual word than "safe."
---
### Author:  [@Centril](https://internals.rust-lang.org/u/Centril)
#### Post date: [March 20, 2018, 11:28pm UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/11 "2018-03-20T23:28:11Z")
Brainstorming… How about:
- “dyn-safe” instead? `#[dyn_trait_safe]` or `#[dyn_safe]`
- `#[erasable]` (type erasure)
If we stick with “object safe” we could do `#[object_safe]`.
---
### Author:  [@Centril](https://internals.rust-lang.org/u/Centril)
#### Post date: [March 20, 2018, 11:38pm UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/12 "2018-03-20T23:38:59Z")
More brainstorming:
1.
```rust
#[dynamic_trait]
trait Foo {}
```
1.
```rust
#[dynamic]
trait Foo {}
```
1.
```rust
#[dyn]
trait Foo {}
```
An argument in favor of attributes is that you don’t have to think about the order between `dyn` and `unsafe` (and possibly `const`) when defining the trait.
---
### Author:  [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)
#### Post date: [March 21, 2018, 9:51am UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/13 "2018-03-21T09:51:57Z")
> [@withoutboats](#):
>
> I don’t like dyn capable (seems supe jargony to me)
I hear you -- open to alternatives.
> [@withoutboats](#):
>
> “dynamic trait type.”
I believe this is what I wrote:
> I think we should start calling dyn Trait types **dynamic trait types**.
> [@withoutboats](#):
>
> If we’re going to require this on every trait, or even every public trait - and I don’t think we should - I wouldn’t want the syntax to be an attribute.
I did not mean to imply it would be required on every trait. But what I was thinking is that any trait that you use with `dyn` would want to be marked `#[dyn_capable]`, so that you know you are using it in the expected way.
I'm not sure how important it is though. I'd be happy to just start with having a way to "opt-in" to those checks. (And not necessarily connect it to _uses_ of `dyn`.)
(Why wouldn't you want it to be an attribute? Attribute feels right to me.)
---
### Author:  [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)
#### Post date: [March 21, 2018, 9:53am UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/14 "2018-03-21T09:53:06Z")
> [@nikomatsakis](#):
>
> Attribute feels right to me
To elaborate: it doesn't affect the meaning of the trait items. It just imposes some restrictions on the trait's future trajectory.
I am not keen on `dyn trait Foo` because it makes it feel (to me) like the trait is "inherently dynamic" or something, or _limited_ to dynamic trait types.
---
### Author:  [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)
#### Post date: [March 21, 2018, 9:56am UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/15 "2018-03-21T09:56:24Z")
> [@Centril](#):
>
> An argument in favor of attributes is that you don’t have to think about the order between dyn and unsafe (and possibly const) when defining the trait.
See, `unsafe trait` feels different -- it is something that implementors of the trait must be aware of (since they need an `unsafe impl`).
Similarly, `const trait` -- if we supported that -- would presumably mean that implementors must have a `const impl` (or all `const fn`, etc).
But `dyn trait` doesn't have that character. It is just about the trait _definition_ (implementors can do whatever).
---
### Author:  [@withoutboats](https://internals.rust-lang.org/u/withoutboats)
#### Post date: [March 21, 2018, 10:07am UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/16 "2018-03-21T10:07:36Z")
> [@nikomatsakis](#):
>
> I did not mean to imply it would be required on every trait. But what I was thinking is that any trait that you use with dyn would want to be marked #[dyn\_capable], so that you know you are using it in the expected way.
That sonunds fine (though I think it should be very optional, analogous to an allow by default lint for example). But when you have dyn\_capable(no) it sounds like dividing the world into two sets, one which can be used as objects and one which can't. That would mean it'd be idiomatic to put this on every trait you define ("to avoid the back compat hazard!"), at which point it shouldn't be an attribute.
---
### Author:  [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)
#### Post date: [March 21, 2018, 10:28am UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/17 "2018-03-21T10:28:46Z")
> [@withoutboats](#):
>
> That sonunds fine (though I think it should be very optional, analogous to an allow by default lint for example). But when you have dyn\_capable(no) it sounds like dividing the world into two sets, one which can be used as objects and one which can’t.
My goal with `#[dyn_capable(no)]` was to allow you to _opt-out_ from being dyn-capable -- even if you otherwise would be -- because you expect to maybe change the trait in incompatible ways in the future, e.g. by adding default fns that are generic or something. But maybe that's not necessary.
---
### Author:  [@kornel](https://internals.rust-lang.org/u/kornel)
#### Post date: [March 21, 2018, 10:45am UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/18 "2018-03-21T10:45:41Z")
+1 for name change.
`dyn trait Foo {}` seems OK. Or `impl dyn for Foo; impl !dyn for Foo;`
I’m not a fan of `#[]` syntax, which seems to be reserved for things that are complex or “oops, we forgot to reserve a keyword for this” escape hatch.
---
### Author:  [@Centril](https://internals.rust-lang.org/u/Centril)
#### Post date: [March 21, 2018, 10:56am UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/19 "2018-03-21T10:56:17Z")
> [@nikomatsakis](#):
>
> But dyn trait doesn’t have that character. It is just about the trait definition (implementors can do whatever).
This is a compelling argument; `unsafe` and `const` have the character of being effects (or restrictions thereof) which `dyn` is not. Instead, `dyn` has an entirely different "category" -- traits of traits (meta traits).
> [@kornel](#):
>
> I’m not a fan of # syntax, which seems to be reserved for things that are complex or “oops, we forgot to reserve a keyword for this” escape hatch.
It can often be that reason, yes; but in this case, I think `dyn trait Foo {}` is misleading for the reason @nikomatsakis voiced: that it makes the trait feel inherently dynamic (or limited to being dynamic).
---
### Author:  [@Ixrec](https://internals.rust-lang.org/u/Ixrec)
#### Post date: [March 21, 2018, 9:00pm UTC](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091/20 "2018-03-21T21:00:49Z")
I also dislike “dynamic trait” because that makes it sound like it’s a property of the trait, not a runtime polymorphic fat pointer to some type implementing that trait. In fact the whole point of adding `dyn` in front of the trait is to make it clear when we’re talking about the trait itself and when we’re talking about some _thing_ that implements the interface defined by the trait. Calling the _thing_ an “[adjective] trait” feels like re-encouraging the exact confusion that we just made this high-churn change to combat.
Unfortunately, I really have no idea what to call the thing other than a “trait object”. Part of me wants to say `&dyn Trait` is a “polymorphic reference”, but that doesn’t provide a name for the unsized `dyn Trait` type, and I don’t know how many people would assume “polymorphic” implies runtime polymorphic the way I do. “dynamic reference” sounds like the reference might sporadically change what it refers to, which is not at all what we want. “dynamic type” is… maybe okay? I have no idea how people would interpret that phrase. And any other term that doesn’t contain the word “dynamic” will probably be no better than “trait object”.
[Next page](https://internals.rust-lang.org/t/proposal-change-terminology-from-trait-object-to-dynamic-trait/7091.md?page=2)