Note naming convention of lists (xs, ys, ...) #15410
Conversation
| > *Note:* Names like `xs` and `ys` are due to a naming | ||
| > convention of collection-like data structures | ||
| > (like our `List`) in which they are given names | ||
| > appended with 's' to signify plurality, ie |
There was a problem hiding this comment.
Should probably be 'i.e.' (or just write the "the data structure stores multiple elements" in brackets).
|
I like this idea, but I don't know what our actual convention is here. I personally like xs. |
|
I don't think we really have a naming convention around lists right now, they're sorta just called what's "most appropriate" I believe. That being said, this seems fine to include. Can you squash the commits together? |
|
@alexcrichton Since I chose to edit the document through the online editor instead of forking, committing locally and then sending a pull request, I don't seem to be able to squash the commits - my fork has not preserved my commits, only the commits at the time of the fork. I guess I would have to fork again, make the appropriate changes locally, and then open a new pull request. Would that be OK? |
|
They're on your patch-1 branch, you can pull it down, squash, and push back up (with force) just like any other branch. |
People reading the tutorial may not be familiar with the convention of naming lists, vectors and the like as xs, ys, etc. Without some explanation of the reasoning behind it, it might come off as just throwaway non-descriptive names. Languages like Haskell gets flak from using short, non-descriptive names, while in reality, there are clear conventions and reasons for using certain terse variable names. I assumed that the convention came from a language like Haskell, so I tailored the explanation according to that.
|
@steveklabnik Thanks for the tip! @alexcrichton I've squashed the commits together now. |
|
Thanks @LemmingAvalanche! |
People reading the tutorial may not be familiar with the convention of naming lists, vectors and the like as xs, ys, etc. Without some explanation of the reasoning behind it, it might come off as just throwaway non-descriptive names. Languages like Haskell gets flak from using short, non-descriptive names, while in reality, there are clear conventions and reasons for using certain terse variable names. This is just a proposed explanation of this convention, as I've interpreted it - I assumed that the convention came from a language like Haskell, so I tailored it according to that. So beware that I might have misjudged how it is used in the Rust language, or at least how it is used in the Rust tutorial.
…eykril internal : rewrite DeMorgan assist fixes rust-lang#15239 , rust-lang#15240 . This PR is a rewrite of the DeMorgan assist that essentially rids of all the string manipulation and modifies syntax trees to apply demorgan on a binary expr. The main reason for the rewrite is that I wanted to use `Expr::needs_parens_in` method to see if the expr on which the assist is applied would still need the parens it had once the parent expression's operator had equal precedence with that of the expression. I used `.clone_(subtree|for_update)` left and right and probably more than I should have, so I would also be happy to hear how I could have prevented redundant cloning.
People reading the tutorial may not be familiar with the convention of naming lists, vectors and the like as xs, ys, etc. Without some explanation of the reasoning behind it, it might come off as just throwaway non-descriptive names. Languages like Haskell gets flak from using short, non-descriptive names, while in reality, there are clear conventions and reasons for using certain terse variable names.
This is just a proposed explanation of this convention, as I've interpreted it - I assumed that the convention came from a language like Haskell, so I tailored it according to that. So beware that I might have misjudged how it is used in the Rust language, or at least how it is used in the Rust tutorial.