Object initializer updates #8253
Conversation
This updates the ref safety rules to better explain how object initializers work.
| var x = new S(ref heapSpan, stackSpan) | ||
| ``` | ||
|
|
||
| This modeling is important because it demonstrates that our [MAMM][rules-method-arguments-must-match] need to account specially for member initializers. Consider that this particular case needs to be illegal as it allows for a value with a narrower *safe-context* to be assigned to a higher one. |
There was a problem hiding this comment.
Should the link be (#rules-method-arguments-must-match) instead?
| The *safe-context* of an object initializer expression is narrowest of: | ||
|
|
||
| 1. The *safe-context* of the constructor call. | ||
| 2. The *safe-context* arguments to member initializer indexers that can escape to the receiver (can escape to *caller-context*) |
There was a problem hiding this comment.
Should this be ref-safe-context of ref arguments to indexers (specifically, an in argument)?
There was a problem hiding this comment.
This is a case of practically speaking no. The in part of an indexer can't escape into this because it's return only. Hmm ... guess you could if it was [UnscopedRef]. Not sure if we have good testing for that. The 99% case is the value is what matters.
Spec wise can say both thogugh.
| } | ||
|
|
||
| // Can be modeled as | ||
| var x = new S(ref heapSpan, stackSpan) |
There was a problem hiding this comment.
Cannot it be modeled simply as this?
var x = new S(ref heapSpan);
x.Field = stackSpan;There was a problem hiding this comment.
Doing it that way would mean that the safe-context of x is calling method because only heapSpan is used in the variable declaration. The motivation for putting all of the other values in the constructor is to solve issues like this.
This updates the ref safety rules to better explain how object initializers work.