FlatSharp 8 Planning

[jamescourtney]

This issue is to track progress and objectives for a future FlatSharp 8 release.

What's wrong with FlatSharp 7?

Nothing major. It works fine! Today, FlatSharp 7 supports .NET Framework, .NET Standard 2.0/2.1, .NET 6, 7, 8, and (soon) 9. This is a robust compatibility matrix. This wide compatibility comes with limitations:

• No way to support 64 bit flatbuffers in a safe way (Span<T> is limited to the 32 bit address space)
• APIs generally have to target the lowest common denominator of language features.
• Adding features such as static interface members introduced compatibility problems between .NET 8 and .NET Standard.

Plans going forward

FlatSharp 8 is an upcoming release that will support .NET 9 (and above) only. FlatSharp 7 will continue to support older versions of .NET in addition to .NET 9. While I don't expect to develop tons more features for FlatSharp 7 going forward, I'm committed to:

• Backporting some features to v7 (as appropriate)
• Supporting security in v7 for the foreseeable future.
• Adding new versions of .NET to FlatSharp v7 for those that don't want to update.

Plans for FlatSharp 8

The introduction of the allows ref struct anti-constraint in .NET 9 is a big deal for FlatSharp. It allows us to remove the explicit dependency on Span<byte>, which will allow supporting 64-bit buffers in turn. In place of a hard dependency on Span<byte>, we'll define something along the following lines:

public interface IFlatBufferSerializationTarget<T> where T : IFlatBufferSerializationTarget<T>
{
    long Length { get; }

    byte this[long index];

    T Slice(long start, long length);

    T Slice(long start);

    Span<byte> AsSpan(long start, int length);
    
    void WriteInt32(long offset, int value);

    void WrintUInt32(long offset, uint value);

    // etc
}

public interface ISerializer<T>
{
     ...
     int Serialize<TTarget>(T item, TTarget target) where TTarget : IFlatBufferSerializationTarget<T>, allows ref struct;
     ...
}

This change will address several structural issues in FlatSharp, such as proper 64-bit support and extensibility.

The Chopping Block

The following features are being considered for removal in FlatSharp 8:

• Object pooling (technically this is a beta and opt-in behavior in v7). However, I've not heard of any examples of real-world use, and it adds quite a bit to my test and development matrix.

Other new features

• ~~In addition to .GetMaxSize(), FlatSharp 8 will expose a .GetActualSize() method, which will return the precise number of bytes necessary to serialize an object.~~
• Other .NET 9 integration points
  • Partial properties
• Support for a "optimize" flag, which allows toggling between "code size" and "raw performance" modes.
• [Obsolete] on deprecated properties. (Breaking change in V7)
• Proper forward-compatibility for union types. Today, FlatSharp will throw an exception when it encounters an unexpected discriminator. V8 should either unknown values and provide a way to make this observable.

[angelofb]

can you publish the compiler as dotnet tool? It would be very handy

[jamescourtney]

can you publish the compiler as dotnet tool? It would be very handy

I'm a little hesitant, but maybe you can persuade me. Basically, any given build of the compiler only works with that build of the runtime. So Compiler 7.8 only promises to work correctly with Runtime 7.8. I'm a little worried that if I publish as a dotnet tool then people will update the compiler without updating the runtime. Is that a real problem? I know you can do that today by changing the version of the compiler's nuget package, but that's a more intentional thing.

[angelofb]

my use case is simply that before starting to use your wonderful library the code was generated by a powershell script for both c# and c++ and differences in generated code were easily inspected by git tools. not a real issue, everything works great, c# code is now generated by flatsharp msbuild and c++ by the same script.

you could check if the generated code matches with the installed runtime like Google.FlatBuffers does,

public static void FLATBUFFERS_24_3_25() {}

but if you think that it creates more problems than it solves you could leave it as it is

maybe you could just add to the documentation section Wiki > Compiler > Command Line Invocation that the same version of compiler and runtime is mandatory