This thread is to document design and other considerations for supporting https://github.com/google/flatbuffers/issues/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?
This thread is to document design and other considerations for supporting https://github.com/google/flatbuffers/issues/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:
IInputBufferinterface changes frominttoulongfor 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: