Navigation Menu

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

lvalue and rvalue should be documented as well #30

Merged
merged 1 commit into from Oct 24, 2018

Conversation

shepmaster
Copy link
Member

No description provided.

@RalfJung
Copy link
Member

Please, let's call them "place" and... "operand" or "value" or so. We probably have to mention "lvalue" in the description of "place" because it is used in C/C++, but it is not a great name.

@shepmaster
Copy link
Member Author

I think whatever the canonical Rust name becomes, you will want these two documented, even if only as redirects to the proper name. Documenting what they are and picking a name for them can be orthogonal.

@steveklabnik
Copy link
Member

We explicitly removed rvalue and lvalue from all Rust docs, in favor of 'place expressions' and 'value expressions' in all documentation a while back: https://doc.rust-lang.org/reference/expressions.html?highlight=place,exp#place-expressions-and-value-expressions

@RalfJung
Copy link
Member

RalfJung commented Sep 18, 2018

At least I was not talking about expressions though, but about the "thing" they evaluate to. 3+4 might be a "value expression", I guess, but it computes to "7" and that's a value, no further computation necessary.

I guess it would be consistent then to say that place expressions evaluate to a place, and value expressions evaluate to a value.

@strega-nil
Copy link

Another important thing is that place expressions can also evaluate to a value, and value expressions can evaluate to a place, if necessary.

First, it's important to note that there are 2 axes on which places can be put - the immutable/mutable axis, the owned/borrowed axis, and the initialized axis (ignored for this comment).

Place-to-value conversion is allowed when, given a place expression e of type T:

  • T: Copy
  • e is owned

Value-to-place conversion is allowed for all values (afaik), and results in a mutable, owned place expression.

@shepmaster
Copy link
Member Author

To be clear, this is just a request that these terms be documented, just like the existing requests for terms. It seems like all of the discussion y'all are having will be lost / not-easily findable when this PR is merged. Perhaps it's appropriate to move that discussion into an issue?

@avadacatavra
Copy link
Contributor

we can also just have something like

  • lvalue/place
    if these are equivalent terms. i'd be in favor of having some disambiguation here (since i have no clue what any of these things mean in any forms :p)

@strega-nil
Copy link

@avadacatavra yeah, the term across the languages is lvalue (C), place (Rust), and glvalue (C++). Basically, it means an expression that refers to a location, as opposed to just a value:

fn main() {
  0; // value expression - 0 is not a place
  let x = 0;
  x; // place expression - x is a place
}

@avadacatavra
Copy link
Contributor

i'd be fine if we wanted to add that to this PR 💯

@avadacatavra
Copy link
Contributor

I'm going to merge this and we can define at some point in time

@avadacatavra avadacatavra merged commit 5d5e812 into rust-lang:master Oct 24, 2018
@shepmaster shepmaster deleted the patch-1 branch October 24, 2018 23:58
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.

None yet

5 participants