search

SFML / SFML.Net

Official binding of SFML for .Net languages
https://www.sfml-dev.org
Other
536 stars 84 forks source link

Add Span APIs #185

Open TrueGoric opened 4 years ago

TrueGoric commented 4 years ago

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: https://github.com/SFML/SFML.Net/issues/174#issuecomment-557927211

DemoXinMC commented 4 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 5 months ago

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.