Skip to content

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

Closed

Description

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

Activity

  1. changed the title [-]Meeting proposal: rename "object safety" to "dyn compatibility[/-] [+]Meeting proposal: rename "object safety" to "dyn compatibility"[/+] on Aug 4, 2024
  2. joshtriplett commented on Sep 9, 2024

    @joshtriplett
    Member

    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

  3. rfcbot commented on Sep 9, 2024

    @rfcbot

    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.

  4. traviscross commented on Sep 17, 2024

    @traviscross
    Contributor

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

  5. rfcbot commented on Sep 17, 2024

    @rfcbot

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

  6. traviscross commented on Sep 17, 2024

    @traviscross
    Contributor
  7. 4 remaining items

  8. rfcbot commented on Sep 27, 2024

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

  9. added a commit that references this issue on Sep 27, 2024
  10. added a commit that references this issue on Sep 28, 2024
  11. added a commit that references this issue on Oct 9, 2024
  12. added a commit that references this issue on Oct 10, 2024
  13. added a commit that references this issue on Oct 16, 2024
  14. added a commit that references this issue on Oct 16, 2024
  15. moved this from Needs triage to Closed in T-lang design meeting scheduleon Nov 6, 2024
  16. cher-nov commented on Nov 23, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions