Lazy<int>, I think not. Even if it could, the values inside wouldn't actually be lazy -- they would have to be constructed at deserialization time. Unless perhaps you were willing to keep the
ReadOnlySequence<byte>that you deserialized from around indefinitely.
Lazy<T>? And now you want to deserialize it lazily using
IEnumerable<T>? Regardless, I imagine there's a few ways to do it, all of which requires that you hold the
ReadOnlySequence<byte>that you deserialize from (or at least parts of it) in memory indefinitely (or until all elements have been fully realized).
By the way, v2 isn't compatible with streaming reading and writing, right?
For writing, we use a chunk link that borrows a buffer from BufferPool,
It is not possible to write by Streaming.
(For IBufferWriter, Flush is not called, so a buffer is created internally)
As for reading, since it is necessary to convert to ReadOnlySequence once, it is not read by streaming.
In other words, A buffer of that size(if data is too large, require large buffer) is required for both writing and reading.
This is not a concern.
I just thought about an API that combines high-speed reading and writing with Streaming.
That hasn't been achieved yet.
-rcor any other suffix so that NuGet/SemVer considers the package stable, and (just as important) we consider the public API stable so that future changes do not break backward compatibility unless we're willing to ship a 3.0 release.
Sequence<T>which allocates many moderately sized arrays so that they don't go to the large object heap, and you don't run out of memory just because you can't allocate a large enough array. If #437 is ever done (set for 3.0 currently) it will allow asynchronous streaming deserialization without sacrificing performance.
However, if stable means not rc, we should require to publish mpc, unitypackage, too.
How close are we to publishing mpc / unitypackage? Is there an issue tracking this? Is #593 tracking something like this?