Added: LDM notes for Dec 5 2018, Dec 12 2018, and Jan 7th, 2019

[agocke]

Dec 5

• Tracked nullable states, their correspondance to source and the rules they follow in flow analysis

Dec 12

• Async-streams misc. questions
• Compat issue with Dispose pattern in foreach

Jan 7

Nullable:

• Variance in overriding/interface implementation
• Breaking change in parsing array specifiers

[HaloFour]

Let's narrow the pattern-based Dispose change down to ref structs only. This means every other type will be required to implement IDisposable.

☹️

[MgSam]

Agree with @HaloFour. Since practically speaking C# 8.0 is largely only for .NET Core (a much smaller and newer subset of all .NET code), I think the bar for breaking changes should be a little lower. Having pattern based Dispose everywhere doesn't seem like that dangerous a change or a very difficult one to resolve if it does break someone somewhere.

[yaakov-h]

Since practically speaking C# 8.0 is largely only for .NET Core

uhhh, what? The only feature that is locked to Core at the moment, AFAIK, is DIM.

[alrz]

A pattern enumerable type did not implement IDisposable, but had a Dispose method. This method would now be call.
If there are two Dispose extension methods, that will now produce an ambiguity and thus a compilation error.

none of which applies to using declarations. is that acceptable to do this only for using decls?

[qrli]

On nullable analysis:
My opinion is that the compiler should focus on the annotation part (expressing the intended nullability) and have a release earlier.

The analysis part, on the other hand, will never be perfect, and it will be a moving target over the long run. So many of the advanced scenarios may be better left to analyzers. That's also a good space for 3rd party analyzers to explore.

[MgSam]

Since practically speaking C# 8.0 is largely only for .NET Core

uhhh, what? The only feature that is locked to Core at the moment, AFAIK, is DIM.

Default interfaces, asynchronous streams, and ranges all require .NET Core as far as I'm aware, because Microsoft has stated they are not making further changes to the .NET Framework.

[gafter]

Asynchronous streams and ranges will work on any platform as long as suitable types with suitable names are available. They don't have to be defined in the framework.

[MgSam]

@gafter Are there plans to release packages for those types that are usable in .NET Framework? My understanding was that that wasn't happening.

[gafter]

@MgSam I don't know. I would be shocked if someone doesn't make such packages available.

[jnm2]

Let's narrow the pattern-based Dispose change down to ref structs only. This means every other type will be required to implement IDisposable.

Not only is this disappointing, it is inconsistent with await using. #2135:

Scenarios:

• using statements and declarations, and foreach should find Dispose() extension methods (on ref structs)

• await using statements and declarations, and await foreach should find DisposeAsync() extension methods (on any type)

[gafter]

it is inconsistent with await using.

Yes, and we would make them consistent if we could do so without breaking compatibility. Since this is crucial for struct types (which cannot implement interfaces), and unnecessary for other types (which can), it seems like the sweet spot.

[jnm2]

Has evidence of the compatibility break been seen in the field?

unnecessary for other types (which can)

It's still necessary if you want to make a non-ref type disposable which you don't own.

[gafter]

Has evidence of the compatibility break been seen in the field?

Yes, there have been many times that we've changed a language feature due to customer-reported breaks. Or are you asking if we've released this feature with an intentional compatibility break? No.

[jnm2]

Has evidence of this compatibility break been seen (customer has explicit IDisposable.Dispose and also an instance or extension Dispose method which is materially different)? Or is the decision (to remove the ability to make third-party types disposable with extension methods) just out of anticipation of the possibility of a break?

[HaloFour]

Would an acceptable compromise be to not support pattern-based dispose specifically with enumerators in foreach statements? That the enumerator instance must implement IDisposable? That would eliminate the concern about breaking changes.

[HaloFour]

I typed that comment up in a restaurant last night so in case I was a little too terse to clearly convey my suggestion I'll expound on it a little:

I'm thinking that in order to keep the rules simple and to avoid any breaking changes that pattern-based disposal only applies when using the using/await using statements. At that point if the target does not implement IDisposable/IAsyncDisposable then it will attempt to resolve any accessible Dispose/DisposeAsync methods, either as instance members or extension methods.

When using foreach/await foreach the compiler will not resolve pattern-based disposal unless the enumerator is a ref struct* (and thus can't implement interfaces) in which case it will attempt to resolve an accessible instance member named Dispose/DisposeAsync. The assumption here is that the enumerator would provide for its own disposal and that it would be spooky if an extension method could interject some disposal logic here.

I don't think that this is very different from the situation with "awaiters" today. They are 90% pattern-based, but are required to implement INotifyCompletion. "Critical" awaiters can also implement ICriticalNotifyCompletion, but it's not possible to "upgrade" an existing awaiter to be a "critical awaiter" via an UnsafeOnCompletion extension method.

* This is a breaking change but I assume that supporting disposal of a ref struct enumerator is one of the use cases that the team wants to support and the chances that this would break any code is quite small due to their proliferation when compared to other pattern-based enumerators.

[gafter]

Has evidence of this compatibility break been seen (customer has explicit IDisposable.Dispose and also an instance or extension Dispose method which is materially different)?

No, we didn't seek to analyze all customer code to find out if there would be a break. We didn't see that part of the feature as important enough for that level of effort. Moreover, the break would arise from extension Dispose methods which people are likely to introduce in the future, thereby silently changing the behavior of existing code, not those extensions that exist today. Anyway I think such use cases would be better served by a hypothetical defer statement.

[jnm2]

@gafter

Moreover, the break would arise from extension Dispose methods which people are likely to introduce in the future, thereby silently changing the behavior of existing code, not those extensions that exist today.

Isn't the IDisposable interface going to be preferred over resolving extension and instance methods? The behavior would then not be able to change unless (besides adding an extension method) the type stopped implementing IDisposable.

And if this is a concern, why is it being enabled for DisposeAsync, and similarly why is foreach going to also start recognizing extension methods?

[MgSam]

@MgSam I don't know. I would be shocked if someone doesn't make such packages available.

"Hopefully the community does it because we're not going to" is equivalent to "not officially supported". Which means that for many customers it just will not be an option.

And even if/when someone does make such packages, it would still mean that you won't be able to use these features in a .NET Standard library targeting both Framework and Core since they'll be .NET Standard 3.0 only, and Framework will never implement .NET Standard 3.0.

I know it's not your team that is responsible for the BCL, but the reality is the decision to drop official Framework support means using C# 8.0 on Framework is going to be difficult, confusing and, in my opinion, avoided.

So maybe since this release is already a breaking change for many C# customers, the bar should be lower about what constitutes a breaking language change.

[HaloFour]

I'd hope that MS would add their own "official" NuGet package for when targeting Framework, like they did for ValueTuple. Otherwise I agree, we don't need a bunch of competing implementations of the same type creating collision and confusion, either for Framework or for .NET Core pre-3.0.

[yaakov-h]

And even if/when someone does make such packages, it would still mean that you won't be able to use these features in a .NET Standard library targeting both Framework and Core since they'll be .NET Standard 3.0 only

You lost me here. If all you need are the basic types like IAsyncEnumerable, and these types can be defined anywhere, why does it necessitate .NET Standard 3.0?

[gafter]

Isn't the IDisposable interface going to be preferred over resolving extension and instance methods?

Dynamically, yes. We test using an is if the type implements IDisposable. The check for the extension method is something that we do statically. We would not just be able to call the extension method when the class doesn't implement IDisposable, because the object might be of a derived type that does implement IDisposable. We would have to generate code that tests if the object implements the interface, and then calls one way (through the interface) or the other (through the extension).