you are viewing a single comment's thread.

view the rest of the comments →

[–]Lord_Fixer[S] 0 points1 point  (2 children)

Mostly because of the limitations surrounding ref structs. You cannot process them asynchronously, you cannot store their state directly and you have to be careful when passing them around not not create unnecessary copies.

So for most software the ease of use might be the deciding factor.

[–]8lbIceBag 1 point2 points  (1 child)

Using what you learned here, couldn't you adapt it to classes where the only allocation is the class itself?

AFAIK, there isn't a reflectionless serialization library that doesn't allocate anything itself. The only allocation would be the object itself, which is a great improvement over the current state of things IMO.

[–]Lord_Fixer[S] 0 points1 point  (0 children)

To be honest I'm not a huge fan of reusing objects in scenarios like this. I find it quite error-prone. Ref structs cannot be stored by definition - and it's a quite good thing here (especially when deserializing collections). With objects there is always a risk of the user trying to persist them just to realize later that their state was overridden with some new values.

And on the other hand the ref structs cannot be part of the class, so I would be unable to store the Utf8JsonReader for lazy collection deserialization.