Variables and Variable References

[RexJaeschke]

This Issue replaces Issue #270, ‘Revising the Definition of “Variable Reference”.’

I’ve put each proposal in a separate Comment, so you can record a thumb-up/down for each.

Defining two kinds of variable references

The key to my proposals below is to have two flavors of variable reference: modifiable and non-modifiable, so we can adequately spec the following V7 features:

• Input parameters
• Methods/delegates with ref returns
• local ref variables
• Conditional expressions having a ref result
• ref assignment

Variable reference

10.5 Variable references says

A variable_reference is an expression that is classified as a variable. A variable_reference denotes a storage location that can be accessed both to fetch the current value and to store a new value.

variable_reference
    : expression
    ;

Note: In C and C++, a variable_reference is known as an lvalue. end note

Proposal 1: We should use the term “variable reference” (rather than “variable”) in all contexts involving an expression that denotes a variable.

[RexJaeschke]

Use of “lvalue”

Proposal 2: As this is the only place in the spec that we use lvalue, rather than correcting the note (because it ignores the C89-invented distinction between modifiable and non-modifiable lvalues), we should delete it.

[RexJaeschke]

Classified as a variable

In the current V6 draft spec, we use the phrase “is [not] classified as a variable” numerous times, all in the context of an expression. Some are declarative statements; others are qualifiers of the form “If is classified as a variable …”

Proposal 3 (initial): Replace all these occurrences with “is [not] a variable_reference.” After all, that’s exactly what a variable reference is!

[RexJaeschke]

Variable

10 Variables|10.1 General says

Variables represent storage locations. Every variable has a type that determines what values can be stored in the variable. C# is a type-safe language, and the C# compiler guarantees that values stored in variables are always of the appropriate type.

Operators needing write access

Proposal 4 (initial): Rewrite

12.7.10 Postfix increment and decrement operators

The operand of a postfix increment or decrement operation shall be an expression classified as a variable, a property access, or an indexer access.

as

The operand of a postfix increment or decrement operation shall be a variable_reference, a property access, or an indexer access.

Likewise, for 12.8.6 Prefix increment and decrement operators, and 12.18 Assignment operators|12.18.1 General.

[RexJaeschke]

My experiment

Ignoring the readonly ref features added by V7.x, for now, I’m concentrating on the simple (existing) case of a readonly field, in the context of ++, --, and assignment. We know these should be rejected, but does the spec say that?

While 12.7.10 Postfix increment and decrement operators, 12.8.6 Prefix increment and decrement operators, 12.18.2 Simple assignment, and 12.18.3 Compound assignment, explicitly require property and indexer operands to have a setter, there is no stated requirement that a variable/variable_reference operand be writable! So, that needs to be addressed.

Variable reference (revisited)

I don’t see any way that the spec requires a variable to be physically write-protected. (Afterall, a readonly field can be written to by a constructor!) However, the spec can allow us to add write-protection when accessing a variable, via a variable_reference. When C89 (the first C standard) borrowed the type qualifier const from C++, it had to revise its idea of lvalue by distinguishing between a modifiable lvalue and a non-modifiable lvalue, and I propose we do the same with variable_reference.

Proposal 5: Change 10.5 Variable references from

A variable_reference is an expression that is classified as a variable. A variable_reference denotes a storage location that can be accessed both to fetch the current value and to store a new value.

to

A variable_reference is an expression that is classified as a variable. A modifiable variable_reference denotes a storage location that can be accessed both to fetch the current value and to store a new value. A non-modifiable variable_reference denotes a storage location that can be accessed to fetch the current value, but not to store a new value.

A given storage location may be denoted by multiple modifiable and non-modifiable variable_references.

[RexJaeschke]

Proposal 3 (final): Re the use of “classified as a variable,” all these occurrences should be replaced with “is a [modifiable|non-modifiable] variable_reference, as appropriate.”

[RexJaeschke]

Operators needing write access (revisited)

Proposal 4 (final):

12.7.10 Postfix increment and decrement operators

The operand of a postfix increment or decrement operation shall be a modifiable variable_reference, a property access, or an indexer access.

12.8.6 Prefix increment and decrement operators

The operand of a prefix increment or decrement operation shall be a modifiable variable_reference, a property access, or an indexer access.

12.18 Assignment operators|12.18.1 General

The left operand of an assignment shall be a modifiable variable_reference, a property access, an indexer access, or an event access.

[RexJaeschke]

Readonly Fields

15.5 Fields|15.5.1 General says

The value of a field is obtained in an expression using a simple_name (§xx), a member_access (§xx) or a base_access (§xx). The value of a non-readonly field is modified using an assignment (§xx). The value of a non-readonly field can be both obtained and modified using postfix increment and decrement operators (§xx)) and prefix increment and decrement operators (§xx).

Proposal 6: Change this to

The value of a field is obtained in an expression using a simple_name (§xx), a member_access (§xx) or a base_access (§xx). A non-readonly field may be denoted by either a modifiable or a non-modifiable variable_reference. A readonly field may be denoted only by a non-modifiable variable_reference.

[RexJaeschke]

Other places that may need edits

Proposal 7: Change 10 Variables|10.1 General

Variables represent storage locations. Every variable has a type that determines what values can be stored in the variable. C# is a type-safe language, and the C# compiler guarantees that values stored in variables are always of the appropriate type. The value of a variable can be changed through assignment or through use of the ++ and -- operators.

To

Variables represent storage locations. Every variable has a type that determines what values can be stored in the variable. C# is a type-safe language, and the C# compiler guarantees that values stored in variables are always of the appropriate type. The value of a variable can be changed via a modifiable variable_reference to that variable, through assignment or through use of the ++ and -- operators.

[RexJaeschke]

Proposal 8: Change 10.2 Variable categories|10.2.1 General

Add here something like “Except for fields marked readonly (§xx) all variables may be denoted by modifiable or non-modifiable variable_references (§xx).”

[RexJaeschke]

Still to come

I have not done an exhaustive search for all places that would be impacted by these changes, but can do that if/when we agree on these approaches.

Once we have the two flavors of variable_reference defined and use them correctly throughout the exiting spec, I can go back to the V7 feature specs and use the new terminology, as appropriate for the new ref/readonly ref cases.