-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Add Pointer tutorial, rename shared pointer tutorial. #9579
Conversation
this: | ||
|
||
```rust | ||
fn succ(x: ~int) -> int { *x + 1 } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to work with the example below, I think this needs to be &int
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed, you need &int to just have a reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops! Fixing.
|
||
Turns out, you don't. All you need is a reference. Try this on for size: | ||
|
||
```rust |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if pandoc takes these backticks as code, I was under the impression that pandoc required the tildes. If it renders just fine though, fine by me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
backticks are perfectly fine in pandoc :)
For smaller structs, this way will be more efficient. For larger ones, it may | ||
be less so. But don't reach for that pointer until you must! Make sure that the | ||
struct is large enough by performing some tests before you add in the | ||
complexity of pointers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section sounds like it could use some clarification in terms of what the codegen actually does. I was under the impression that this was a pointer under the hood, but I may be wrong. Regardless though, it'd be awesome if this were explicit about when it's a pointer and when it's a copy (if ever)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I would love some more detail here, I just don't have the chops.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Store" on line 148 should be "stores," as you're referring to the singular entity Rust.
This is pretty awesome! Always nice to see some more documentation :) I'm not sure if they belong in these tutorials, but there are two topics related to pointers which probably warrant tutorials:
Thanks for writing these up! |
hm, perhaps I should just read the lifetimes tutorial... nevermind! |
|
||
# Managed Pointers | ||
|
||
Managed pointers, represented by an `@`, are used when having a single owner |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
represented => notated, perhaps?
Overall, looks good to me. Thanks so much! |
@alexcrichton mutability would be a good section to add, yes! I'll do that soon. @cmr any time. I'm just happy to have a good place to point people... |
Actually, maybe mutability does require its own tutorial. Hmm. |
@alexcrichton yeah, I think we should make a mutability tutorial. if you want to get together on IRC and eli5, I can write something up. |
What channel are you guys in? |
I'm not sure if we should really have a separate tutorial for this stuff - I'm convinced it can be explained in simple terms in the main tutorial. We make it out to be far more complicated than it is. |
I'm convinced we should be improving the tutorial and manual before we consider making another tutorial (or extending the borrowed pointer tutorial). I think the new Boxes section demonstrates that we can reach a point where the use case and semantics are communicated in simple terms. I'm going to work more on incorporating the ideas we had for this into the tutorial and we can revisit whether we need anything separate down the road. I don't think we will. |
…r=llogiq let `upper_case_acronyms` check the enum name Signed-off-by: TennyZhuang <zty0826@gmail.com> Fix rust-lang#9579 changelog: [`upper_case_acronyms`]: check the enum name
Three things here:
I've written a brand new tutorial, 'pointers.' This gives an overview of pointers and explains best practices around using them.
I've renamed the 'borrowed pointers and lifetimes' tutorial the the 'lifetimes' tutorial, since that's really what it's about. I cut out some of the stuff that was explained in the new pointer tutorial. These two felt better separate than together.
Three: one or two things related to my rustpkg tutorial; while looking for places to add my new one, I realized I left one or two things out, I guess?