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 thread is to document design and other considerations for supporting google/flatbuffers#7537. Support for this in FlatSharp will be nontrivial, but is something that people periodically ask for.
On a whim, the set of issues that need to be resolved are:
IInputBuffer interface changes from int to ulong for indices (or, nuint).
Alternative to Span<T> that supports 64 bit indexes. Possibly a SpanWindow<T> that could return a span over a given window.
Some 64 bit collection replacement for IList<T>, which also only supports 32 bit indexes.
This will constitute a breaking API change for FlatSharp. Further, this will likely require the project to cross a couple of bridges that I've resisted so far:
Dependencies on non-Microsoft libraries (Microsoft does not provide 64 bit collections, Spans, Memory, Arrays, etc).
Use of unsafe code
All told, this will be more difficult in C# than it really should be. Further, I'm curious about whether people truly want to see this supported. I'm also curious how we'll cross-validate this with google/FlatBuffers C# given that they are likely to run into many of the same 32 bit limitations that FlatSharp is.
So, the questions are:
Can FlatSharp (as a C# project) support this?
What changes and dependencies would be needed to do so? Given this new set of dependencies and changes, should FlatSharp support this?
Are there vetted, secure, and trustworthy 64 bit implementations of Collections, Memory, Span, and other "primitives" that FlatSharp could leverage?
The text was updated successfully, but these errors were encountered:
This thread is to document design and other considerations for supporting google/flatbuffers#7537. Support for this in FlatSharp will be nontrivial, but is something that people periodically ask for.
On a whim, the set of issues that need to be resolved are:
IInputBuffer
interface changes fromint
toulong
for indices (or,nuint
).Span<T>
that supports 64 bit indexes. Possibly aSpanWindow<T>
that could return a span over a given window.IList<T>
, which also only supports 32 bit indexes.This will constitute a breaking API change for FlatSharp. Further, this will likely require the project to cross a couple of bridges that I've resisted so far:
All told, this will be more difficult in C# than it really should be. Further, I'm curious about whether people truly want to see this supported. I'm also curious how we'll cross-validate this with google/FlatBuffers C# given that they are likely to run into many of the same 32 bit limitations that FlatSharp is.
So, the questions are:
The text was updated successfully, but these errors were encountered: