move to c# 8 in LangVersion

[SimonCropp]

is there any point in holding back on using the new features?

[JimBobSquarePants]

I'm a little concerned about the statement in this blogpost.

Many of the C# 8.0 language features have platform dependencies. Async streams, indexers and ranges all rely on new framework types that will be part of .NET Standard 2.1. As Immo describes in his post Announcing .NET Standard 2.1, .NET Core 3.0 as well as Xamarin, Unity and Mono will all implement .NET Standard 2.1, but .NET Framework 4.8 will not. This means that the types required to use these features won’t be available on .NET Framework 4.8. Likewise, default interface member implementations rely on new runtime enhancements, and we will not make those in the .NET Runtime 4.8 either.

For this reason, using C# 8.0 is only supported on platforms that implement .NET Standard 2.1. The need to keep the runtime stable has prevented us from implementing new language features in it for more than a decade. With the side-by-side and open-source nature of the modern runtimes, we feel that we can responsibly evolve them again, and do language design with that in mind. Scott explained in his Update on .NET Core 3.0 and .NET Framework 4.8 that .NET Framework is going to see less innovation in the future, instead focusing on stability and reliability. Given that, we think it is better for it to miss out on some language features than for nobody to get them.

[SimonCropp]

the compiler wont let u use async streams or async dispose if u target netstandard 2.0 (or any of the fworks that target it). u would need to do conditional compilation in those scenarios, which may be worth it in some cases

[SimonCropp]

i have the same problem in several of my tools. they are consumed in msbuild. which is locked into net47, so i cant use async streams or async dispose

[JimBobSquarePants]

For this reason, using C# 8.0 is only supported on platforms that implement .NET Standard 2.1.

It's this that concerns me the most. What do they mean by supported? I'd love to use the new features but I don't want to end up with obscure, target dependent, jit errors.

[SimonCropp]

that is the official stance. mostly because they dont want to get into the conversation with people about what parts of c#8 do not work in netstandard2. but the features that are pure IL do work. scoped usings, nullable ref types etc. i have updated ~50 projects over the past few months to do exactly that.

[SimonCropp]

FWIW i have found null refs bugs in approx 30% of the projects i have moved over to nullable ref types

[JimBobSquarePants]

i have updated ~50 projects over the past few months to do exactly that.

Then if the build works I'm up for it. I'd like to experiment to reduce scope capturing with static local functions.

[antonfirsov]

Hmm nullable ref types - I (we?) still need to learn a few things about that. Especially the bits regarding how it affects public API-s of software libraries, and our non-C#8 consumers.

[JimBobSquarePants]

nullable ref types

I wouldn't worry. I don't think we'll ever use them. Maybe if we were starting from scratch but not now.

FWIW i have found null refs bugs in approx 30% of the projects i have moved over to nullable ref types

I'd maybe enable temporarily just for checking but I think there's too much risk here to leave enabled.

[SimonCropp]

I'd maybe enable temporarily just for checking but I think there's too much risk here to leave enabled.

whats the risk? it is a compile time feature, not runtime

[JimBobSquarePants]

whats the risk? it is a compile time feature, not runtime

Virility, This is a huge complicated codebase and we could end up disappearing down a rabbit hole for weeks altering the codebase as we chase down issues.

That said, I am curious to see what goes bang if we turned it on globally.

[SimonCropp]

ok leave this pr open. and i will try to get some time to explore that rabbit hole and report back

[codecov]

Codecov Report

Merging #1033 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1033      +/-   ##
==========================================
- Coverage   89.87%   89.87%   -0.01%     
==========================================
  Files        1104     1103       -1     
  Lines       48922    48896      -26     
  Branches     3445     3441       -4     
==========================================
- Hits        43971    43944      -27     
- Misses       4248     4249       +1     
  Partials      703      703

Impacted Files	Coverage Δ
src/ImageSharp/Memory/Buffer2DExtensions.cs	80% <0%> (-4.85%)	⬇️
...essing/Processors/Drawing/FillProcessor{TPixel}.cs	93.33% <0%> (-0.11%)	⬇️
...ssing/Processors/Transforms/Resize/ResizeWorker.cs	98.66% <0%> (-0.04%)	⬇️
src/ImageSharp/Formats/Jpeg/JpegConstants.cs	100% <0%> (ø)	⬆️
src/ImageSharp/Memory/Buffer2D{T}.cs	100% <0%> (ø)	⬆️
...s/Convolution/Convolution2PassProcessor{TPixel}.cs	100% <0%> (ø)	⬆️
tests/ImageSharp.Tests/Memory/Buffer2DTests.cs	100% <0%> (ø)	⬆️
...essors/Convolution/ConvolutionProcessor{TPixel}.cs	100% <0%> (ø)	⬆️
src/ImageSharp/Memory/RowInterval.cs	100% <0%> (ø)	⬆️
...ing/Processors/Transforms/CropProcessor{TPixel}.cs	100% <0%> (ø)	⬆️
... and 7 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c59a32e...785821d. Read the comment docs.

[JimBobSquarePants]

Fixed with #1082