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

Inconsistent naming of mut methods (get_mut vs. mut_iter) #13660

Closed
mbrubeck opened this issue Apr 21, 2014 · 4 comments · Fixed by #17268
Closed

Inconsistent naming of mut methods (get_mut vs. mut_iter) #13660

mbrubeck opened this issue Apr 21, 2014 · 4 comments · Fixed by #17268
Assignees
Milestone

Comments

@mbrubeck
Copy link
Contributor

The Rust stdlib sometimes uses prefix mut_ and other times suffix _mut. This is a really minor papercut, but it does cause me to mistype names on a regular basis.

For example, we have:

find_mut
get_mut
front_mut
back_mut
borrow_mut

...but also:

mut_iter
mut_slice
mut_last
mut_split_at
@brson brson added the A-libs label Apr 22, 2014
@brson
Copy link
Contributor

brson commented Apr 22, 2014

Another conventions issue. Nominating.

@brson brson added this to the 1.0 milestone Apr 25, 2014
@brson
Copy link
Contributor

brson commented Apr 25, 2014

P-backcompat libs, 1.0

@lilyball
Copy link
Contributor

find_mut, get_mut, and borrow_mut to me seem fine. Those are verbs, not nouns. mut_iter, mut_slice, etc are nouns. So the former is saying "do this thing, mutably". The latter is saying "return this mutable thing".

front_mut and back_mut seem like the latter, which suggests they should be mut_front and mut_back.

mut_split_at is an interesting case, as "split" is both verb and noun. I think it's correct as-is. split_mut_at and split_at_mut both suggest there's a non-mutable split_at, which there isn't. I think it's ok to read this as "return a mutable split at (index)". There's also a parallel between mutable split and mutable slice.

@aturon
Copy link
Member

aturon commented Aug 4, 2014

The guidelines now have a convention for this placement. I will be rolling them out in a patch soon.

bors added a commit that referenced this issue Sep 16, 2014
As per [RFC 52](https:/rust-lang/rfcs/blob/master/active/0052-ownership-variants.md), use `_mut` suffixes to mark mutable variants, and `into_iter` for moving iterators. Additional details and motivation in the RFC.

Note that the iterator *type* names are not changed by this RFC; those are awaiting a separate RFC for standardization.

Closes #13660
Closes #16810

[breaking-change]
bors added a commit that referenced this issue Sep 16, 2014
As per [RFC 52](https:/rust-lang/rfcs/blob/master/active/0052-ownership-variants.md), use `_mut` suffixes to mark mutable variants, and `into_iter` for moving iterators. Additional details and motivation in the RFC.

Note that the iterator *type* names are not changed by this RFC; those are awaiting a separate RFC for standardization.

Closes #13660
Closes #16810

[breaking-change]
bors added a commit to rust-lang-ci/rust that referenced this issue Jan 9, 2023
…et, r=jonas-schievink

Fix: Handle empty `checkOnSave/target` values

This fixes a regression introduced by rust-lang#13290, in which failing to set `checkOnSave/target` (or `checkOnSave/targets`) would lead to an invalid config.

[Fixes rust-lang#13660]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants