-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Do something with IReadOnlyCollection and ICollection. We needs good abstractions hierarchy. #20399
Comments
Too late. Too late. It means never. But it's every day pain. We need to do something like not-nullable reference (see dotnet/csharplang#219) or define version of CoreFX with this breaking change. For example "DotNet Ultra" scheduled to 2025 - will be next major Dotnet rewrite, where this problem will be solved. |
As you recognize I don't believe we'd take any breaking change of that sort any time soon. Countless code already uses them. |
Removing is certainly not an option at this point. However, we've talked with the compiler and runtime team to see if we could make the mutable interfaces inherit from the read-only interfaces. AFAIR the consensus is that we probably could, but we'll have to make sure it's not a source/IL breaking change. So far, the impact of the work didn't seem to be worth it. @dmitriyse assuming our mutable interfaces would extend the read-only interfaces, would this be sufficient? Also note that we do have immutable interfaces in the |
Ok, I understand how deep is a rabbit hole. Hypothetical "DotNet Ultra" in 2025 will be probably backward compatible to current CLR binaries. And probably we will get D# that works side by side with C# 12.0 on-top of the same CLR, but have no any inherited problems of C#(and have no old-code compile restriction). This hypothetical D# can finally get more popularity than C# and finally any current C# problems could be solved. But next 7 years until 2025 we needs to work on C#. But seriously:If we will think carefully we will infer that:
public class MyCollection:ICollection
{
// It's in IReadOnlyCollection, but it's ok in C# 6.0+
int ICollection<int>.Count {
get
{
return _someCount;
}
}
} and finally this point requires not so big change in the compiler. So what was broken with CoreCLR
ConclusionBreaking changes of ICollection: IReadOnlyCollections are very the same as .Net 4.5 / CoreCLR breaking changes. The only additional required step was a compiler feature with relaxation: public class MyCollection:ICollection
{
// It's in IReadOnlyCollection, but it's ok in C# 6.0+
int ICollection<int>.Count {
get
{
return _someCount;
}
}
} |
Unfortunately looks like with CoreCLR is too late. But I hope at least this can be planned to 2025 year. Currentl we can only improve toolset/compiler to allow annotation of classes/argumets/properties/variables with "readable" and add compile-time analysis. Exactly the same thing that will be done in C# 8.0 with not-null references. They will add two mode to C# compiler,
P.S Toolset VS 2015 + R# + ImplicitNullability + JetBrains.Annotations.NotNull already works like C# 8.0. |
|
I added more close to reality proposals related to this thread. Possibly annotation and compile-time analysis is a wrong way. |
As stated this is a breaking change we wouldn't like to take at this point or soon. So we are closing it for now. Thanks @dmitriyse for your proposal and feel free to bring up more :) |
Just drop IReadOnly****, mark them obsolete.
We can't do anything with backward compatibility here.
If we inherit ICollection from IReadOnlyCollection we will broke existing code.
See: http://stackoverflow.com/questions/12622539/why-doesnt-generic-icollection-implement-ireadonlycollection-in-net-4-5
But may be sometime will be good point do do this breaking change, provide tools for migration automation.
And also IReadOnly*** is not clear solution, we needs IReadable*** and IImmutable****
This is not-null reference types like problem. But it's second after nullability.
Let's start/continue to solve this problem.
The text was updated successfully, but these errors were encountered: