Inline array of struct assignment
Hey,
I am trying to implement something using inline arrays, however I am struggling to get a way to do it in a clean way.
gets
I am sure this worked in preview .net 8.
Does anyone have any experience using inline arrays yet. It feels rough having to have some kind of proxy struct and i wish you could do this on the field/property level.
14 Replies
the problem is more or less that u get a copy of the actual value/backing field of the auto property
even if that would compile, u would not be able to observe the change
u can probably fix that by having a getter that returns a
ref Buffer10<Header>
but then u expose the whole thing and make it mutable in every way
eg like this
but i think the cleanest way here would be to split it up into a public getter only property for a ReadOnlySpan<Header>
and using an explicit internal field
it could also be that its actually complaining about the HeadersCount++
if thats a property 🤔Do i need to implement AsSpan for my Buffer10?
i mixed up what the compiler generates and edited the code afterwards, u use
MemoryMarshal.CreateSpan()
or MemoryMarshal.CreateReadOnlySpan()
for whatever u want.
as u usually do not expose this buffer type directly, it most likely doesnt deserve having such a methodokay its compiling now thank you, I will try and play with it
I does feel very strange having the Buffer10. If I have some place that needs 10 and some which needs 10 am i expect to just have Buffer1-100 or something?
in the end, yes
Why wouldn't they have just codegenned it and wrapped it in a way so you can declare it similar to a regular heap allocated array?
tbh i also dont name them that generalized but some explicit stuff for whatever i use it for, like
file struct CharacterListDataBuffer<T>
If its that specific why would I use T?
why they decided to do it like that is probably a question for #roslyn
ah, its just an example from one of my buffers.
i basically get a packet as response where i have max 10 entries and its either an int, ushort or a string, and u cant
stackalloc
reference type spans and need to use inline arrays for thatYeah we are planning to use it for packet structs
I guess I feel like im not meant to use it how im using it.
i think u simply shouldnt expose it at all on the public API surface, there u should use
Span<T>
or ReadOnlySpan<T>
instead
because how big the internal buffer is ... is an internal implementation detail
its also a thing, currently u have a length of 10, what will u do if that changes in the future?
adjust the attribute parameter and rename the type? cant really do that because other types might use a Buffer10<T>
as well and it would break binary and maybe source compatibility
creating another type? breaks binary/source compatibility too
so thats more or less the best way to do it on the API surface, most likely also in the internalThanks for your help btw
glad i could help o7
if u think ur question is answered, dont forget to $close the thread
Use the /close command to mark a forum thread as answered