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

Fixed an error in tutorial.md #11494

Closed
wants to merge 1 commit into from
Closed

Fixed an error in tutorial.md #11494

wants to merge 1 commit into from

Conversation

dannycoates
Copy link

The freezing reference section described lending an immutable pointer but the example and logic suggest it should be a mutable pointer.

The freezing reference section described lending an *immutable* pointer but the example and logic suggest it should be a *mutable* pointer.
@huonw
Copy link
Member

huonw commented Jan 12, 2014

The example just below that piece of text is showing an immutable reference; a mutable reference would be created with let z = &mut x;.

In any case, while it's true that taking a mutable reference (e.g. z above) to a value stops mutation through any other pointer, it doesn't freeze the object: you can mutate it through z. However, the existence of any immutable reference stops all mutation, through any reference (or even directly mutating the object).

@alexcrichton
Copy link
Member

Closing, I agree with @huonw that the text is correct as-is. A mutable reference is indeed allowed to mutate the object, while taking an immutable reference does indeed freeze the object and prevent all mutation of the object.

@dannycoates
Copy link
Author

Though after reading your explanation makes it clear, the text is confusing as is. I believe the language, "Lending an immutable pointer" isn't clear to someone unfamiliar with Rust, like me, who is just learning the terminology, whereas "Taking an immutable reference" as @alexcrichton describes here is perfectly clear to me, and probably others coming from a C perspective.

Just my 2 cents :)

flip1995 pushed a commit to flip1995/rust that referenced this pull request Nov 2, 2023
…affects_lint, r=Centri3

fix enum_variant_names depending lint depending on order

changelog: [`enum_variant_names`]: fix single word variants preventing lint of later variant pre/postfixed with the enum name

fixes rust-lang#11494

Single word variants prevented checking the `check_enum_start` and `check_enum_end` for being run on later variants
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 this pull request may close these issues.

3 participants