doc: more consistent comments about vector types. #11796
Conversation
|
@lecram Hm, I wonder what the balance is of snippets that use backticks to those that don't. I'm a markdown junkie so my inclination is that, yes, we should always use them both in code-in-comments and in code-in-comments-in-examples. I'd be curious about what others think though. |
|
@huonw concurs. |
|
There are about the same amount of snippets on the tutorial that uses backticks for code-in-comments and that don't. Something like ten of each. Should file names in comments be enclosed in backticks too? |
|
Agreed with @brson. Comments are text (semantically-wise) and backticks separate code elements from text. |
|
@lecram I lean toward backtick filenames too. |
|
Thanks for the feedback. Please note that this Pull Request is not about backticks. For this reason I created a separate PR, trying to solve the backticks matter (see #11996). Specifically, this Pull Request is about the confusion that may arise from statements like this one:
Reading that in an official tutorial, one might think that there is some special relation between slices and the type |
This Pull Request aims to add backticks to all instances of code inside comments in snippets present in tutorial.md. It also includes backticks for filenames in the same conditions. See #11796 for motivation.
|
Closing due to a lack of activity, but feel free to reopen with a rebase! |
Closes rust-lang/rust-clippy#10118 This lint checks `map_or` method calls to check if they can be consolidated down to something simpler and/or more readable. For example, the code ```rs let x = Some(5); x.map_or(false, |n| n == 5) ``` can be rewritten as ```rs let x = Some(5); x == Some(5) ``` In addition, when the closure is more complex, the code can be altered from, say, ```rs let x = Ok::<Vec<i32>, i32>(vec![5]); x.map_or(false, |n| n == [5]) ``` into ```rs let x = Ok::<Vec<i32>, i32>(vec![5]); x.is_some_and(|n| n == [5]) ``` This lint also considers cases where the `map_or` can be chained with other method calls, and accommodates accordingly by adding extra parentheses as needed to the suggestion. changelog: add new lint `unnecessary_map_or`
No description provided.