Add Span APIs

[TrueGoric]

As the Span functionality has rocked the .NET world some time ago and is sure to stay, it would be great to see it implemented in SFML.Net.

I am willing to commit my time and submit a PR, however, as this library targets netstandard2.0, this would mean either upgrading to netstandard2.1 (possibly breaking some projects) or dual targeting with an additional dependency on System.Memory.

A question for the maintainers: is it be okay to add such a dependency?

Edit: Possibly related: #174 (comment)

[DemoXinMC]

For the time being, I think it's best we stay on standard 2.0. .NET 5 will potentially be changing a lot of how things are done, and something that requires updating to a new standard would be best if done at the same time as whatever changes are useful for .NET 5

[hawkerm]

It's fairly straight-forward to multi-target for .NET 6 and .NET Standard 2.1 to get those benefits, but then keep support for .NET Standard 2.0 by including the System.Memory package when running there, see this example: https://github.com/CommunityToolkit/dotnet/blob/main/src/CommunityToolkit.Diagnostics/CommunityToolkit.Diagnostics.csproj

There's also projects like https://github.com/Sergio0694/PolySharp to help as well.

[eXpl0it3r]

On the surface such things often seem "straight-forward", the question is then much more, whether it also holds up in the details.

Personally, I'd hold off on a Span API and thus .netstandard2.1 until SFML 3 / SFML.Net 3. However if someone can provide a .netstandard2.0 compatible implementation, we could also consider it for earlier use.

Having just gone through .NET Framework to .NET 6 migration, I personally know how painful it is, when .netstandard2.0 isn't supported. While we don't necessarily have made any compatibility promises, I feel like it could cause a lot of headaches, if SFML.Net 2.x stops being compatible with .netstandard2.0. We'd need some pretty strong reason to break this compatibility.

[hawkerm]

Sorry, I was trying to say you can still use the Span APIs with .NET Standard 2.0 today without having to bump to .NET Standard 2.1.

I was trying to say in fact that you can multi-target, so if someone is running on a newer runtime then they get performance improvements. This is what the .NET Community Toolkit does for their High Performance package.

[eXpl0it3r]

I have change my opinion on the topic slightly. I do see the benefit of keeping netstandard2.0 around for as long as possible and would rather add System.Memory as NuGet package, if it means we can keep netstandard2.0

Whether we can really keep netstandard2.0 for all potential changes in SFML 3, remains to be seen.