Discussion: C# Design Review Notes for Mar 25, 2019

[yaakov-h]

Note: I took it upon myself to create this issue since there wasn't one already.

C# Design Review Notes for Mar 25, 2019

We brought in the design review team to look at some of our recent and open decisions in C# LDM.

1. Nullable reference types: shipping annotations
2. Pattern-based indexing with Index and Range
3. Cancellation tokens in async streams

---

We therefore recently decided to drop sidecar files, at least for now. The review team agreed with this. Instead we should double down on annotating the .NET Core libraries themselves.

What happens with .NET Framework? Will new Reference Assemblies be produced that contain annotations, or would we have to wait until .NET 4.9 or similar to ship with nullability annotations?

Or is Microsoft going to [continue to] ignore .NET Framework completely, and have another language feature that is semi-exclusive to .NET Core?

[orthoxerox]

Does this approach mean there will be no way to annotate existing versions of external assemblies?

[Unknown6656]

Or is Microsoft going to [continue to] ignore .NET Framework completely, and have another language feature that is semi-exclusive to .NET Core?

I do hope not.
I'll be happy to switch to .NET Core, however, some APIs such as System.Drawing (or System.Windows.Forms) do not have a very efficient .NET Core alternative .... so I'm depending on the traditional .NET Framework.
I hope that features such as NRT or Ranges/Indices will not be .NET Core-exclusive.

[benaadams]

however, some APIs such as System.Drawing (or System.Windows.Forms) do not have a very efficient .NET Core alternative

System.Drawing is currently available to .NET Core via Microsoft.Windows.Compatibility NuGet and System.Windows.Forms is now open source on github https://github.com/dotnet/winforms and avilable as part of the upcoming .NET Core 3.0 (though only on Windows)

[gafter]

Does this approach mean there will be no way to annotate existing versions of external assemblies?

You are welcome to create your own reference assemblies with annotations.

[YairHalberstadt]

For Index the compiler can synthesize the behavior from int-based indexers and access to a Length or Count property.

Does that mean this will compile:

        var dic = new Dictionary<int, int>();
        var x = dic[^1];

And if so, is that worth doing anything about?

Moved from caf9e90#r32997853

[gafter]

@YairHalberstadt It is an open issue whether indexers declared to take a type parameter but constructed so that the indexer takes an int would satisfy the requirements to be an int-based indexer for this purpose. We suspect it should not. But it has not been settled.

[orthoxerox]

@gafter will there be a guide accompanying the release on how to make a reference assembly for, say, some old release of Newtonsoft.JSON?

[yaakov-h]

@gafter

You are welcome to create your own reference assemblies with annotations.

And for the BCL?

If you just need somebody to figure out which things are nullable and which are not, a lot of that work has already been done.

[Thaina]

Could you please describe the Cancellation tokens in async streams with sample code?

[scalablecory]

@Thaina

async IAsyncEnumerable<int> Foo()
{
    if(cancellationToken.IsCanceled) yield break; // cancellationToken is automatically in scope, and holds myToken.

    yield return 0;
    yield return 1;
    yield return 2;
}

Foo().GetEnumerator(myToken);

[Thaina]

@scalablecory And what about sending myToken in foreach syntax?

[scalablecory]

@Thaina I believe that is already settled; an extension method like IAsyncEnumerable<T>.WithCancellation(cancellationToken) will be used.

[gafter]

@orthoxerox

will there be a guide accompanying the release on how to make a reference assembly for, say, some old release of Newtonsoft.JSON?

I am not aware of any such documentation effort, but contributions are most welcome!

[BhaaLseN]

I'll be happy to switch to .NET Core, however, some APIs such as System.Drawing (or System.Windows.Forms) do not have a very efficient .NET Core alternative .... so I'm depending on the traditional .NET Framework.

...or, APIs that are not available at all, like WCF hosting (not client!) with Net.Tcp, Named Pipes and MSMQ transport.
This pretty much keeps us from moving to .NET Core at this point, since rewriting everything in a different framework (whether it is on top of HTTP based WebAPI or gRPC) is just not feasible (nor something we'd necessarily want, for cases where .NET to .NET communication that moves a lot of data over Net.Tcp and works-just-fine™ with very little performance penalties while HTTP bindings just cannot keep up). And I'm not even touching on local machine interprocess communication scenarios where spinning up in-process web-servers feels overkill.

_{But this is supposed to be about the C# language and getting NRT annotations, so I'll shut up for now}

[Unknown6656]

@BhaaLseN : * and System.IO.Ports etc.

[svick]

@Unknown6656 Based on https://github.com/dotnet/corefx/issues/18012, I believe System.IO.Ports will be supported cross-platform in .Net Core 3.0.