Meeting proposal: rename "object safety" to "dyn compatibility"

[notriddle]

Summary

Instead of calling them "object safe," refer to traits that support vtables as being "dyn compatible."

Background reading

https://internals.rust-lang.org/t/object-safety-is-a-terrible-term/21025

About this issue

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.

[joshtriplett]

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]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

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]

@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]

🔔 This is now entering its final comment period, as per the review above. 🔔

[traviscross]

cc @ehuss

[fmease]

I'll open draft PRs for rustc and the std lib shortly.

Edit:

• Compiler: Rename "object safe" to "dyn compatible" rust#130826
• Library: Rename "object safe" to "dyn compatible" rust#130827

[traviscross]

I've created a tracking issue for this here:

• Tracking issue for rename from "object safe" to "dyn compatible" rust#130852

[rfcbot]

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.

[cher-nov]

To be honest, the whole "trait object" term is awful.

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

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