ShadowMarker789
commented
3 weeks ago .Net Framework totally hasn't reached EOL.
Since the .Net Framework is a part of Windows itself - the Windows support lifecycle applies to the entirety of the versions of Framework that the OS supports.
With Windows 11 still fully supporting .Net Framework, it'll be many, many years for it to still be used and relevant, particularly in the enterprise space (where I still use it, for reference).
Unless you have very specific needs (such as interface default implementations, interface static methods, unmanaged function-pointer jangling) I don't think there's anything that you can't do in NS2.0.
I am confident that one can expose out a modern .Net API for the entirety of SFML3.0 so long as the capabilities are exported sufficiently in CSFML.
Not that I ever expect .Net Framework to "really die" anyway.
Besides, .NET Framework 4.8 was only released Apr 18, 2019. That's not ancient.
I thought to create an issue to collect some of the ideas that have been floating around, that could potentially be implemented with SFML.Net 3. Feel free to add your comments on any topic below. If something requires a bigger discussion, we can always split into separate issue.
IEnumerable<Vertex>TimeSpaninstead ofSFML.System.Time.NET Version
Currently SFML.Net uses netstandard2.0 which provides maximal support for .NET Framework as well as .NET 6+
I'm of the opinion that as a library we should try to retain maximal support for as long as possible. As such I'm advocating for staying with netstandard2.0 and pulling in "polyfill" NuGet packages as needed.
At the same time, I do acknowledge that .NET Framework has long reached its EOL, even if it's still "supported" by Microsoft and thousands of applications still using it. As such I'm also open to move away from netstandard2.0, breaking support for .NET Framework, in the cases where a feature is very beneficial but not netstandard2.0 compatible.
Does multi-targeting provide any benefits?