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.
4 participants
This updates the ref safety rules to better explain how object initializers work.