-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reword trait-object compatibility in rustdoc #126554
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your initiative! I do agree with all of the points raised.
However, I'd like to see some official T-lang-blessed proposal. Basically what Josh has proposed here: https://internals.rust-lang.org/t/object-safety-is-a-terrible-term/21025/13 to ensure that we update the terminology everywhere consistently and "all at once" (docs, diagnostics, rustdoc, …).
Edit: I think Josh suggested to open a proposal over at https://github.com/rust-lang/lang-team.
☔ The latest upstream changes (presumably #126788) made this pull request unmergeable. Please resolve the merge conflicts. |
@rustbot labels -I-lang-nominated When this ongoing FCP completes, we will have decided to call traits that are compatible with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new nomenclature is "dyn-compatible", "dyn-compatibility". PR needs adjusting. See also rust-lang/lang-team#286
@@ -954,13 +954,13 @@ fn item_trait(w: &mut Buffer, cx: &mut Context<'_>, it: &clean::Item, t: &clean: | |||
if !t.is_object_safe(cx.tcx()) { | |||
write_section_heading( | |||
w, | |||
"Object Safety", | |||
"Trait-Object Safety", | |||
"object-safety", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"object-safety", | |
"dyn-compatibility" |
might need to update other references of this ID
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a nit, one would probably say that "a trait is dyn compatible" (but one might "have a dyn-compatible trait"), in the same way that we're more likely to hyphenate "a forward-compatible change" than "a change that is forward compatible".
Similarly, I'd probably say "dyn compatibility" unhyphenated, in the same way "forward compatibility" most often is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that makes sense (attributive vs. predicative usage). I went for unconditional hyphenation here and in my other "object safe → dyn compatible" PRs for legibility (well, that's slightly subjective I guess).
Apart from personal preference, my argument goes as follows: If you skim source code comments and documentation, a "stray" dyn has a good chance of tripping up your brain (well, that's my assumption) especially since it's jargon, not everyday language and since brains are prone to overlooking small words.
Anyway, I'm fine with conditional hyphenation here as you've suggested (since it probably looks better in the rendered HTML and my "source code skimming" argument doesn't really apply).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tho note that this specific string should stay hyphenated for unrelated reasons – it represents the element ID.
@@ -954,13 +954,13 @@ fn item_trait(w: &mut Buffer, cx: &mut Context<'_>, it: &clean::Item, t: &clean: | |||
if !t.is_object_safe(cx.tcx()) { | |||
write_section_heading( | |||
w, | |||
"Object Safety", | |||
"Trait-Object Safety", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Trait-Object Safety", | |
"Dyn-Compatibility", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Trait-Object Safety", | |
"Dyn Compatibility", |
"object-safety", | ||
None, | ||
&format!( | ||
"<div class=\"object-safety-info\">This trait is <b>not</b> \ | ||
"<div class=\"object-safety-info\">This trait is <strong>not</strong> compatible with \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"<div class=\"object-safety-info\">This trait is <strong>not</strong> compatible with \ | |
"<div class=\"dyn-compat-info\">This trait is <strong>not</strong> compatible with \ |
and updating its references
"object-safety", | ||
None, | ||
&format!( | ||
"<div class=\"object-safety-info\">This trait is <b>not</b> \ | ||
"<div class=\"object-safety-info\">This trait is <strong>not</strong> compatible with \ | ||
<a href=\"{base}/reference/items/traits.html#object-safety\">\ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should leave a FIXME(dyn_compat_renaming): Update the URL fragment once the changes in <https://github.com/rust-lang/reference/pull/1512> reach stable
.
<a href=\"{base}/reference/items/traits.html#object-safety\">\ | ||
object safe</a>.</div>", | ||
<code>dyn Trait</code> types</a>.</div>", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I guess "dyn Trait types" is fine and easy to understand. The official term is "trait object types" but that might be too jargon-y, it's hard to tell for me ^^' I use the latter all the time.
@kornelski I've opened a "competing" PR, namely #131594, which is in line with T-lang's latest resolution and a bit more comprehensive. I hope that's not too brash ^^'. Thing is, I'm having a good run updating various places that need updating and I want to land the renaming "simultaneously" (well, within the same release and ignoring the URL staging issue). |
…pat, r=notriddle rustdoc: Rename "object safe" to "dyn compatible" Supersedes rust-lang#126554: 1. In line with [T-lang's latest resolution](rust-lang/lang-team#286 (comment)). 2. More comprehensive: Not only updates user-facing text but also source code. Part of rust-lang#130852. Doesn't update rustdoc-JSON (will be filed separately). r? `@notriddle` (rust-lang/lang-team#286) `@GuillaumeGomez` (for visibility)
Rollup merge of rust-lang#131594 - fmease:rustdoc-mv-obj-safe-dyn-compat, r=notriddle rustdoc: Rename "object safe" to "dyn compatible" Supersedes rust-lang#126554: 1. In line with [T-lang's latest resolution](rust-lang/lang-team#286 (comment)). 2. More comprehensive: Not only updates user-facing text but also source code. Part of rust-lang#130852. Doesn't update rustdoc-JSON (will be filed separately). r? `@notriddle` (rust-lang/lang-team#286) `@GuillaumeGomez` (for visibility)
Closing in favor of the now merged #131594. kornelski, thanks for your initial PR and for bringing up this topic in the first place! |
"Object Safety" is a difficult to understand jargon. I'm proposing a wording that makes it clearer it's about trait objects, and mentions
dyn Trait
which is the syntax that users are going to be more familiar with.Related PR: rust-lang/reference#1512
Longer explanation: https://internals.rust-lang.org/t/object-safety-is-a-terrible-term/21025