You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Meeting proposal: rename "object safety" to "dyn compatibility" #286
This issue corresponds to a lang-team design meeting proposal. It corresponds to a possible topic of discussion that may be scheduled for deeper discussion during one of our design meetings.
Reacted by Ralf Jung, scottmcm, Brad Gibson, Félix Fischer, Jeff Parsons, Shoyu Vanilla, Filipe Rodrigues, runiq, teor, Yerkebulan Tulibergenov and 30 more
changed the title [-]Meeting proposal: rename "object safety" to "dyn compatibility[/-][+]Meeting proposal: rename "object safety" to "dyn compatibility"[/+]on Aug 4, 2024
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
I agree that dyn compatible is a better term to describe which traits may be used with dyn. Specifically, I'd probably frame it that dyn-safety / trait object safety is something that Rust ensures, and that what it requires from users is that they write dyn compatible traits.
To be honest, the whole "trait object" term is awful.
Traits themselves are not instantiable and therefore cannot be objects in the common sense of this word. Quite the contrary: it is a type that is the subject of trait-imputed behavior.
This term has a strong association with the object-oriented paradigm and thereby is simply misleading. I understand the obvious need to refer to "dynamic dispatch", "late binding" and "virtual methods", but it would be much more logical just to use (one of) them directly and make a disclaimer "you know, this is what we ended up using instead of OOP in this (part of the) universe".
Activity
[-]Meeting proposal: rename "object safety" to "dyn compatibility[/-][+]Meeting proposal: rename "object safety" to "dyn compatibility"[/+]joshtriplett commentedon Sep 9, 2024
We talked about this at today's meeting, and we're generally in favor of making this change. Starting an FCP to confirm.
@rfcbot merge
rfcbot commentedon Sep 9, 2024
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
traviscross commentedon Sep 17, 2024
@rfcbot reviewed
I agree that dyn compatible is a better term to describe which traits may be used with
dyn. Specifically, I'd probably frame it that dyn-safety / trait object safety is something that Rust ensures, and that what it requires from users is that they write dyn compatible traits.rfcbot commentedon Sep 17, 2024
🔔 This is now entering its final comment period, as per the review above. 🔔
traviscross commentedon Sep 17, 2024
cc @ehuss
4 remaining items
rfcbot commentedon Sep 27, 2024
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
This will be merged soon.
Rollup merge of rust-lang#130826 - fmease:compiler-mv-obj-safe-dyn-co…
Unrolled build for rust-lang#130826
Rollup merge of rust-lang#130827 - fmease:library-mv-obj-save-dyn-com…
Unrolled build for rust-lang#130827
Rollup merge of rust-lang#131594 - fmease:rustdoc-mv-obj-safe-dyn-com…
Unrolled build for rust-lang#131594
Rollup merge of #131594 - fmease:rustdoc-mv-obj-safe-dyn-compat, r=no…
Rollup merge of #130827 - fmease:library-mv-obj-save-dyn-compat, r=ib…
cher-nov commentedon Nov 23, 2024
To be honest, the whole "trait object" term is awful.
Traits themselves are not instantiable and therefore cannot be objects in the common sense of this word. Quite the contrary: it is a type that is the subject of trait-imputed behavior.
This term has a strong association with the object-oriented paradigm and thereby is simply misleading. I understand the obvious need to refer to "dynamic dispatch", "late binding" and "virtual methods", but it would be much more logical just to use (one of) them directly and make a disclaimer "you know, this is what we ended up using instead of OOP in this (part of the) universe".
See, for example, here for an example of confusion:
https://stackoverflow.com/questions/27567849/what-makes-something-a-trait-object
Frankly, I'd be happy to see one day an RFC covering reduction of the amount of self-inflicted and arbitrarily homegrown terminology in Rust, with the case of UFCS term misuse being an obvious example of this from the past.
https://en.wikipedia.org/w/index.php?title=Uniform_Function_Call_Syntax&oldid=1247021182#Rust_usage_of_the_term
https://doc.rust-lang.org/1.82.0/reference/expressions/call-expr.html#disambiguating-function-calls
rust-lang/rfcs#1140
rust-lang/rfcs#3366
I do not consider writing it myself due to lack of the Rust language knowledge (I am still learning it) and the ashaming level of my English.