terminology for values that are guaranteed to live in memory and have a stable address versus values that are not

[zygoloid]

Summary of issue:

Informally, there has been some use of the terms "l-value" and "r-value" to refer, respectively, to values that live in memory and have a stable address versus values that might not be stored in a stable location in memory. This is confusing, given that in C and C++, "lvalue" and "rvalue" are kinds of expression, not kinds of value, and refer to a static categorization of expressions based on what operations are permitted on those expressions. If we want to talk about something different than the traditional meaning, we should pick new, distinct terms, that differ by more than just the addition of a hyphen.

Details:

One example where this has come up is in values returned from a function. A function call expression is an rvalue expression in C++ terminology (it can't be assigned to nor have its address taken), but people have been describing it as "returning an l-value" given that the returned object has an observable, stable address, as is exposed by return var declarations in the callee.

Any other information that you want to share?

It would make sense to avoid using the terms "lvalue" and "rvalue" in Carbon's design with the C++ meanings, given that they too are confusing, because they are categories of expression but look like they're categories of value. Rust uses the terms "place expression" and "value expression" for these; we could adopt something similar. Explorer internally uses "var" and "let" to refer to the value category, and we could use "var expression" and "let expression" in the design documentation too.

[micttyl]

Dear readers

• Place Expressions and Value Expressions

[tkoeppe]

Could you perhaps summarize/link to some background: What is a "value" in Carbon? What is a value other than the result of an evaluation [of an expression], and what is the distinction between "values" and "kinds of expression"?

[geoffromer]

What is a "value" in Carbon? What is a value other than the result of an evaluation [of an expression], and what is the distinction between "values" and "kinds of expression"?

"The result of an evaluation of an expression" seems like a pretty good working definition of "value"; I'm not sure why you want something other than that. In particular, I think it effectively captures the distinction between the two: expressions are static elements of the source code of the program, whereas values occur dynamically, during execution of the program.

[tkoeppe]

expressions are static elements of the source code of the program, whereas values occur dynamically, during execution of the program.

OK, that makes sense, but what is the need to distinguish the two: are there expressions that do not uniquely determine whether a value resulting from their evaluation has a stable address in memory?

[geoffromer]

Yes. For example, function call expressions are always r-values, because Carbon doesn't have references. However, depending on the function body, the actual returned value may have an address (for example, if it uses returned var).

[inbal2l]

expressions are static elements of the source code of the program, whereas values occur dynamically, during execution of the program.

OK, that makes sense, but what is the need to distinguish the two: are there expressions that do not uniquely determine whether a value resulting from their evaluation has a stable address in memory?

I don't know if it's of any help, but I recently gave a talk at C++Now2022 summarizing the topic and giving the up-to-date status of value categories in C++, including a brief intro to the latest C++23 feature - deducing this (which is an interesting topic by itself, reviewed in a great talk by Ben Deane (one of the feature's authors)).

[eeshvardasikcm]

Dear readers

• Place Expressions and Value Expressions

Rust language documentation details the types, uses, effects, and otherwise, of each expression in various contexts.

Solution to this issue is a study that consists of categorizing the types, uses, effects, and otherwise, of each expression in every possible context. Code language vocabulary already existing in the industry should naturally advance carbon-lang documentation.

Place expressions and value expressions are described briefly in Rust documentation like this:

"Expressions are divided into two main categories: place expressions and value expressions; there is also a third, minor category of expressions called assignee expressions. Within each expression, operands may likewise occur in either place context or value context. The evaluation of an expression depends both on its own category and the context it occurs within.

A place expression is an expression that represents a memory location. These expressions are paths which refer to local variables, static variables, dereferences (*expr), array indexing expressions (expr[expr]), field references (expr.f) and parenthesized place expressions. All other expressions are value expressions.

A value expression is an expression that represents an actual value."

[eeshvardasikcm]

What is a "value" in Carbon? What is a value other than the result of an evaluation [of an expression], and what is the distinction between "values" and "kinds of expression"?

"The result of an evaluation of an expression" seems like a pretty good working definition of "value"; I'm not sure why you want something other than that. In particular, I think it effectively captures the distinction between the two: expressions are static elements of the source code of the program, whereas values occur dynamically, during execution of the program.

Current expression precedence design terminology and variable design terminology, could be used to progressively solve this issue.

This issue appears to be bringing the future concept designs of globals and constants into current terminology.

Avoiding l-value and r-value terminology may be difficult until a later stage, considering expression precedence is a current leading design, while globals and constants are furture concepts.

docs/design/expressions/README.md

"Expressions are interpreted based on a partial precedence ordering."

docs/design/variables.md

"In this proposal, "variable" is defined as an identifier referring to a mutable value."

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. \n\n\n This issue is labeled inactive because the last activity was over 90 days ago.

[jonmeow]

@zygoloid I've triaged this to a "leads question", but would you prefer something like a "design idea" label?

[zygoloid]

@chandlerc I believe your "Values, variables, and pointers" proposal will resolve this.

[josh11b]

#2006 has been accepted, and I believe resolves this question with the terms "value expressions," "reference expressions," and "initializing expressions" defined here: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/values.md#expression-categories and https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p2006.md#values-objects-and-expressions

[chandlerc]

Agree with @josh11b and marking this as decided by the terminology in #2006 -- there was pretty good consensus on the terms we ended up with there.