Skip to content
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

fix indefinite article in cell.rs #79983

Merged
merged 1 commit into from
Feb 12, 2021
Merged

fix indefinite article in cell.rs #79983

merged 1 commit into from
Feb 12, 2021

Conversation

petar-dambovaliev
Copy link
Contributor

No description provided.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @sfackler (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 12, 2020
@@ -1532,7 +1532,7 @@ impl<T: ?Sized + fmt::Display> fmt::Display for RefMut<'_, T> {
/// `UnsafeCell<T>` is a type that wraps some `T` and indicates unsafe interior operations on the
/// wrapped type. Types with an `UnsafeCell<T>` field are considered to have an 'unsafe interior'.
/// The `UnsafeCell<T>` type is the only legal way to obtain aliasable data that is considered
/// mutable. In general, transmuting an `&T` type into an `&mut T` is considered undefined behavior.
Copy link
Member

@jyn514 jyn514 Dec 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This depends how you pronounce &T. I say "a reference type", but it sounds like the original author pronounced it "and-t".

Git says the author was @alexcrichton (e5da6a7) - Alex, what do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could be true...but couple of lines later you can see it being written the way i did it.

/// - If you create a safe reference with lifetime `'a` (either a `&T` or `&mut T`

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And then below again, it uses an:

/// accesses (_e.g._, through an `&mut UnsafeCell<_>`): neither the cell nor the wrapped value

I think either they should all be consistent (and probably this would need a tracking issue because there's so many places it's inconsistent now), or it's not worth changing. I don't think it makes sense to just change this one article.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you create an issue, I can go for it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, but we should decide whether to use 'a' or 'an' first. @steveklabnik do you have an opinion?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I indeed pronounce this "and-t" and "and-mute-t", but I do not have an opinion on whether it's right or not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it's tricky because it technically depends on how you pronounce it. I do what @alexcrichton does most of the time, though often "amp" and not "and," not that that changes the rules here.

https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md is the canonical reference for how we word things. It does not directly address this issue, though it does contain the phrase "an &str," probably because of "string slice" rather than &T where T = str."

words are hard.

Copy link
Contributor Author

@petar-dambovaliev petar-dambovaliev Dec 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I indeed pronounce this "and-t" and "and-mute-t", but I do not have an opinion on whether it's right or not.

I honestly couldn't imagine how you are pronouncing this and it being correct.
Sorry but can you write out the an exact phrase? The only thing I have in my head is an reference type and an mutable reference type which are obviously wrong.

@jyn514 jyn514 added the A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools label Dec 13, 2020
@Dylan-DPC-zz
Copy link

r? @Dylan-DPC

looks good to me and seems consistent with others

@crlf0710
Copy link
Member

Triage: What's next steps here?

@jyn514
Copy link
Member

jyn514 commented Jan 15, 2021

Triage: What's next steps here?

This needs

  1. Consensus on whether to use "a" or "an"
  2. A tracking issue for all the places that need to be changed
  3. Someone to actually put in the work changing things (it sounds like @petar-dambovaliev is volunteering)

The hard part is 1, the others just take time. Personally I think this isn't worth spending a lot of time on, but I'm happy to review PRs if we can somehow decide which article to use. I do not have a strong preference on which article.

@Dylan-DPC-zz
Copy link

@steveklabnik let me know your thoughts on this

@steveklabnik
Copy link
Member

My thoughts are: language is not statically typed, either is fine. I don't have a preference.

@Dylan-DPC-zz
Copy link

Going to merge this as is, we can make it consistent later.

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Feb 11, 2021

📌 Commit 2b9ba46 has been approved by Dylan-DPC

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 11, 2021
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Feb 11, 2021
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Feb 12, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 12, 2021
Rollup of 16 pull requests

Successful merges:

 - rust-lang#79983 (fix indefinite article in cell.rs)
 - rust-lang#81831 (Don't display `mut` in arguments for functions documentation)
 - rust-lang#81947 (Relax ItemCtxt::to_ty lifetime)
 - rust-lang#81954 (RELEASES.md 1.50: Group platform support notes together)
 - rust-lang#81955 (bootstrap: Locate llvm-dwp based on llvm-config bindir)
 - rust-lang#81959 (Fix assosiated typo)
 - rust-lang#81964 (Fix documentation not showing on localStorage error)
 - rust-lang#81968 (bootstrap: fix wrong docs installation path)
 - rust-lang#81990 (Make suggestion of changing mutability of arguments broader)
 - rust-lang#81994 (Improve long explanation for E0542 and E0546)
 - rust-lang#81997 (dist: include src/build_helper as part of the crate graph for rustc-dev)
 - rust-lang#82003 (Stack probes: fix error message)
 - rust-lang#82004 (clean up clean::Static struct)
 - rust-lang#82011 (Fix private intra-doc warnings on associated items)
 - rust-lang#82013 (Tell user how to fix CI file being not up to date)
 - rust-lang#82017 (Fix typo in mod.rs)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 0b6876c into rust-lang:master Feb 12, 2021
@rustbot rustbot added this to the 1.52.0 milestone Feb 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants