You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This changes .locals init to .locals at the IL level;
This can make a measurable and worthwhile difference for some scenarios, especially where stackalloc etc is used; for "normal" code, "definite assignment" rules means this is safe; however, there are a few unsafe and stackalloc scenarios where you need to be careful - for example, your fresh stackalloc data will not be zero'd - needs a code review in particular around any stackalloc or "fixed buffer" scenarios.
This is on-by-default in most framework code, and is well understood. Example here
readonly
Marking non-mutating methods on struct types as readonly (when the struct is not itself readonly) has significant advantages for code that uses in or ref readonly semantics (which might be inside your library, or in consumer code) - avoiding a defensive copy of the struct. This should be fully automated via IDE0251 - you should be safe to blindly accept IDE0251 project-wide; for example, for SpanByte it should be fine for Pointer, ToPointer(), Serialized, MetadataSize, Length get, TotalSize, LengthWithoutMetadata, Invalid get, ToPointerWithMetadata, ExtraMetadata get, AsSpan(), AsReadOnlySpan(), AsSpanWithMetadata(), AsReadOnlySpanWithMetadata(), Deserialize(), ToMemoryOwner(), ToByteArray(), ToString(), CopyTo(), TryCopyTo() - and possiibly a few others!
in some cases you might need to cheat, for example changing Unsafe.AsPointer(ref payload) to Unsafe.AsPointer(ref Unsafe.AsRef(in payload)) (which is JITted away to nothing, but makes the compiler happy to readonly)
Happy to contribute some time towards this if they're desirable
The text was updated successfully, but these errors were encountered:
I wanted to discuss these before jumping in;
skip locals init
This changes
.locals init
to.locals
at the IL level;This can make a measurable and worthwhile difference for some scenarios, especially where
stackalloc
etc is used; for "normal" code, "definite assignment" rules means this is safe; however, there are a fewunsafe
andstackalloc
scenarios where you need to be careful - for example, your freshstackalloc
data will not be zero'd - needs a code review in particular around anystackalloc
or "fixed buffer" scenarios.This is on-by-default in most framework code, and is well understood. Example here
readonly
Marking non-mutating methods on
struct
types asreadonly
(when thestruct
is not itselfreadonly
) has significant advantages for code that usesin
orref readonly
semantics (which might be inside your library, or in consumer code) - avoiding a defensive copy of the struct. This should be fully automated via IDE0251 - you should be safe to blindly accept IDE0251 project-wide; for example, forSpanByte
it should be fine forPointer
,ToPointer()
,Serialized
,MetadataSize
,Length get
,TotalSize
,LengthWithoutMetadata
,Invalid get
,ToPointerWithMetadata
,ExtraMetadata get
,AsSpan()
,AsReadOnlySpan()
,AsSpanWithMetadata()
,AsReadOnlySpanWithMetadata()
,Deserialize()
,ToMemoryOwner()
,ToByteArray()
,ToString()
,CopyTo()
,TryCopyTo()
- and possiibly a few others!in some cases you might need to cheat, for example changing
Unsafe.AsPointer(ref payload)
toUnsafe.AsPointer(ref Unsafe.AsRef(in payload))
(which is JITted away to nothing, but makes the compiler happy toreadonly
)Happy to contribute some time towards this if they're desirable
The text was updated successfully, but these errors were encountered: