Consider dropping some legacy framworks

[SimonCropp]

so we can leverage newer .net features

• span
• ireadonlylist
• ireadonlyspan

[SimonCropp]

IMO net6, netstandard2, net472

[mmanela]

@SimonCropp Thanks for filing this. I am not against dropping older support if we have a compelling change to make (like adopting span to improve perf). However, one of the goals I have for this project is being maximally compatible so that any improvement can help the greatest number of projects even if they are stuck on very old framework versions. So, I want to weigh improvements against that view and make sure the improvement is worth the loss of compatibility.

Thoughts?

[SimonCropp]

my reasoning

• net472 was released in 2018-04. and it should be trivial for people to move to that from net47 which was released in 2017-04
• net6 was released in 2021-11, it is the current LTS version, supported till 2024-11. net5 went out of support in 2022-5. net3.1 went out of support in 2022-12
• netstandard2 is a catch all for some extension based frameworks that require libs to target netstandard2. eg roslyn analysers, c# source generators. there is a negative side effect that netstandard2 implies support in earlier frameworks (eg 4.6.1 and netcore 2.0) but in my projects i handle that with documentation

Up for debate is if u still want to support 4.6.2. released in 2016-8 and supported till 2027-1. u can see the APIs added in net47 https://github.com/microsoft/dotnet/blob/main/releases/net47/dotnet47-api-changes.md
i think the only problematic thing in tuple support. there is a polyfill package System.ValueTuple, but it not seamless. AFAIK it was the first attempt from MS to back port a language feature to an earlier runtime. if u google 4.6.2 tuple u can see some of the problems.

As for api+langfeature compat, we can use a polyfill lib.

• https://github.com/SimonCropp/Polyfill
• https://github.com/Sergio0694/PolySharp
• https://github.com/Tyrrrz/PolyShim

Refs:

• https://en.wikipedia.org/wiki/.NET_Framework_version_history
• https://en.wikipedia.org/wiki/.NET

[mmanela]

@SimonCropp Thanks for the detailed response and I am supportive of this. Ideally, we would do this change along with improvements that take advantage of the newer framework versions.

[SimonCropp]

@mmanela ok. i will gradually make changes and trim TFM as required. and we can discuss in each PR