* Parameter does not escape annotation
This updates the low level struct proposal section on annotations for
parameters that do not escape. This is intended to remove low level
friction points that result from using `ref struct` as arguments to
instance methods on `ref struct`.
* Update proposals/low-level-struct-improvements.md
Co-authored-by: Fred Silberberg <fred@silberberg.xyz>
* Apply suggestions from code review
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Fred Silberberg <fred@silberberg.xyz>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
* NRT spec updates
This makes the following updates to the NRT spec
- Examples for scenarios that commonly trip up customers
- Clarification on when expressions have the null state "maybe default"
vs. "maybe null"
- Minor langauge cleanup
* PR feedback
* PR feedback
Changed "data class" in examples to "record" and some other adjustments to conform more with records.
Also swapped position of "partial" and "abstract" because apparently the compiler only likes it the other way.
To get the examples to compile the classes that contain the records ("Shape", "Binary" and "Expr") should also be changed to record but I left that out for now.
* Proposal: Low level struct improvements
This design covers adding the following features to C# for low level
struct performance improvements:
- Allowing `ref struct` to contain `ref` fields.
- Allowing `struct` and `ref struct` to return `ref` to their fields.
- Allowing safe fixed buffers for unmanaged and managed types.
Note: the section on providing parameter escape notations is incomplete
at this time. I will send a PR in the future once I finalize this
portion. Feel free to still leave comments though.
Iterations
* Rename to ThisRefEscapes
The name `[RefEscapes]` was causing a lot of confusion in the
discussions. People were mis-interpretting it as a general feature that
could apply to other constructs when in reality it's a very specific and
targetted feature. Renaming to `[ThisRefEscapes]` to make it clear this
is a very targetted feature.
* Allow heap inputs
Based on feedback from several people I've decided that we need to make
the rules for `ref` fields more flexible when the values being passed
around are known to refer to the heap. In those cases there is simply no
reason to restrict the created `ref struct` as it is always
*ref-safe-to-escape* to the enclosing method as well as not requiring
any adjustment to the method invocation rules.
This does mean that we need to add the notion of "refers to the heap" to
the span safety document. That doesn't change any assumptions there.
It's just that before this change the notion of "refers to the heap"
wasn't necessary to describe our safety rules.
Co-authored-by: Ruikuan <liruikuan@outlook.com>
Co-authored-by: Joseph Musser <me@jnm2.com>
* Update records spec with new warning
* Update proposals/csharp-9.0/records.md
Co-authored-by: Fred Silberberg <fred@silberberg.xyz>
Co-authored-by: Fred Silberberg <fred@silberberg.xyz>
