Is there a spec for this behavior anywhere that explains why this isn't a compile error?

Is there a spec for this behavior anywhere that explains why this isn't a compile error?

I do not think this needs a specific mention in a spec. A spec for a regular discard support should be sufficient. There is nothing special about this scenario in my opinion - the value being assigned is evaluated and then it is discarded (dropped on the floor).

There is nothing special about this scenario in my opinion - the value being assigned is evaluated and then it is discarded (dropped on the floor).

I do not agree. I went and looked at our speclet for this feature, and it does not imply this code should compile.

The right operand must be an expression that yields an lvalue designating a value of the same type as the left operand.

A discard expression is not an expression that yields an lvalue.

A discard expression is not an expression that yields an lvalue.

Feel free to adjust the speclet, if you feel it needs that. As you can see this PR doesn't change behavior for the scenario and there was no intention to do so.

BTW, how is the fact that "discard expression is not an expression that yields an lvalue" different for non-ref assignments?

We are probably lacking speclet for Discard Expression (or the speclet itself) relaxing the statement for Assignment operator to include discard expression as valid left operand: "The left operand of an assignment shall be an expression classified as a variable, a property access, an indexer access, or an event access."

BTW, how is the fact that "discard expression is not an expression that yields an lvalue" different for non-ref assignments?

We have no spec for discard assignments at all.

. I went and looked at our speclet for this feature, and it does not imply this code should compile.

Don't think that applies here. That is a speclet for ref reassignment. Effectively when you're taking an existing ref local and repointing it at a new location. A discard is not an existing value. I know there is no formal spec for them but the LDM notes that do exists for discards seem to strongly indicate that

Discards are like unassigned variables, and do not have a value.
In general, whenever use of standalone _ as a discard is precluded, either by syntactic restrictions or by _ being declared in the scope, var _ is often a fine substitute with the same meaning

I thought a bit about whether allowing _ = ref M() was an intended behavior or not based on the available notes or if the intent was to not allow it and force developers to do _ = M() instead. But it's impossible to decide that from the notes. Eventually I decided to think about whether or not it's a useful behavior. Eventually I concluded that it is a useful behavior. Consider the following

struct ReallyReallyBigStruct { 
 ... 
}

ref ReallyReallyBigStruct M() { ... } 

In the case you want to invoke M to get the side effects it's valuable to use _ = ref M() instead of _ = M() because it avoids the senseless copying of the ReallyReallyBigStruct instance.

We have no spec for discard assignments at all.

This is the root problem IMHO. This feature was done before we got more rigorous with spec work. As such we're left to infer meaning. In this case the syntax's been allowed for 5+ years now, it's a useful distinction so should just go about ensuring it has the intended semantics.

Don't think that applies here. That is a speclet for ref reassignment.

The reason I went to that spec is because that's the one that added = ref expr to the allowable set of things on the right-hand side of an assignment_expression, which is what we're talking about here.

In the case you want to invoke M to get the side effects it's valuable to use _ = ref M() instead of _ = M() because it avoids the senseless copying of the ReallyReallyBigStruct instance.

I suppose this does make sense. Given that, I'll approve, though I think we'll want @MadsTorgersen / @BillWagner to make sure the ECMA committee considers discard assignments when spec'ing out ref-reassignment.

Don't think that applies here. That is a speclet for ref reassignment.

The reason I went to that spec is because that's the one that added = ref expr to the allowable set of things on the right-hand side of an assignment_expression, which is what we're talking about here.

In the case you want to invoke M to get the side effects it's valuable to use _ = ref M() instead of _ = M() because it avoids the senseless copying of the ReallyReallyBigStruct instance.

I suppose this does make sense. Given that, I'll approve, though I think we'll want @MadsTorgersen / @BillWagner to make sure the ECMA committee considers discard assignments when spec'ing out ref-reassignment.