-
-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Span APIs #185
Comments
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
|
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 There's also projects like https://github.com/Sergio0694/PolySharp to help as well. |
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. |
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. |
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. |
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)
The text was updated successfully, but these errors were encountered: