Clarify unit expressions section of reference #24738
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (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. 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 CONTRIBUTING.md for more information. |
|
You should update it to say that |
|
Huh, guess I'm pretty behind that development! Going to need to update more than just that section by the looks of it if that's the case, but I'll start with just 7.2.4. Can I just append another commit, or should I squash the old one? New to the rust-lang repo. |
|
Actually, it looks like a little more than some editing to that section will be needing. Maybe even removing that section altogether? I probably ought to rescind this PR. |
|
Yeah, this was removed. You can add a new commit, but before merging, we'll want to squash it down. |
|
Wait, have we officially stopped referring to While it is perhaps interesting to look at it as a trivial empty tuple, I am not sure if there is all that much pedagogical value there. . . the phrase "unit type" has a lot of meaning in terms of the conventions about where such types are used (which match up well with how they are used in Rust...) |
I'm not sure, to be honest. But it's not at type anymore. |
|
I agree with you pnkfelix. () is still a type, but it's classified among the tuple types. And to keep the nickname unit type seems useful. It ought to have a good name since it's the default expression and function return value. |
|
☔ The latest upstream changes (presumably #25320) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Yeah, I can do it based off graue's comments on #25244. As for that close, github closes the pull request if the branch has no differing commits for a moment, as it did when I deleted my old commit via a force push. Hopefully it will reopen when the new commits are pushed. |
|
Okay, there we go! |
| @@ -3316,6 +3316,9 @@ assert!(b != "world"); | |||
| assert!(p.0 == 10); | |||
| ``` | |||
|
|
|||
| For historical reasons and convenience, the tuple type with no elements (`()`) | |||
| is often called "unit" or "the unit type." | |||
There was a problem hiding this comment.
Can you
- use single instead of double curlies
- put the period outside of the single curlie
- use actual curlie quotes rather than
'(there are some in this file if you want to copy/paste them.
|
Awesome, thanks! Just a few nits about the curlies, and also, can you put 'Fixes #25244' in the commit text, so when this gets merged, it closes the associated issue. Thanks! |
|
Yeah, I forgot to match the style of the rest of the ref—had my Strunk & White blinders on, I guess. It should be up to snuff now! |
|
It's all good! Thanks :) |
|
@bors: r+ rollup |
|
📌 Commit b87056f has been approved by |
|
⌛ Testing commit b87056f with merge c4d064f... |
|
💔 Test failed - auto-mac-64-nopt-t |
|
@bors: retry On Tue, Jun 16, 2015 at 8:18 AM, bors notifications@github.com wrote:
|
The "unit value" is a value of the "unit type," not the "unit value type." Regardless of correctness, this straight syntax is easier to grok. Part of #16676 Sorry if something's off here, it's my first pull request to rust!
The "unit value" is a value of the "unit type," not the "unit value type." Regardless of correctness, this straight syntax is easier to grok.
Part of #16676
Sorry if something's off here, it's my first pull request to rust!