-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[API Proposal]: ReadOnly empty collection singletons #76028
Comments
Any potential risks? From a discoverability standpoint they seem pretty nice, and possibly a pattern we could be introducing in other interface types. |
Not that I'm aware of. It just hasn't been expressible until relatively recently (C# 8 if memory serves). |
For |
Discoverability and consistency across the interfaces. There's no performance benefit I can think of. |
Should we be using private implementations for each these interfaces or does returning Array.Empty suffice? Assuming we do the latter, Hyrum's law dictates that users will take a dependency on the underlying type being an array, but I don't foresee this needing to change. |
Unless we can optimize something better than what array does, I think we should just use Array.Empty. |
ReadOnlyObservableCollection seems to be a good candidate too |
This will invariably lead to people taking a dependency on these values being actual arrays. Of course, nobody should do that but it's going to happen. This could make future changes to these properties difficult from a compatibility standpoint. Maybe it's safer to have a private implementation. For example, a reflection-based serializer might take a different path based on runtime type. |
That's a good point, actually. Any reflection-based serializer using polymorphism might provide divergent serialization contracts for empty instances. |
What does using the interface members look like --
|
That |
Right, I figured the return type is something that could be navigated, once you've found the thing. But I defer to API experts. |
And is there value in considering adding |
There might be value in a |
Would this cause confusions, as the proposed static properties would be inherited? For example, if For other languages like VB or F#, would static interface members be difficult to consume? |
That's already there in the list. |
namespace System.Collections.ObjectModel
{
public partial class ReadOnlyCollection<T>
{
public static ReadOnlyCollection<T> Empty { get; }
}
public partial class ReadOnlyDictionary<TKey, TValue>
{
public static ReadOnlyDictionary<TKey, TValue> Empty { get; }
}
public partial class ReadOnlyObservableCollection<T>
{
public static ReadOnlyObservableCollection<T> Empty { get; }
}
} |
FWIW, I just ran into a situation today where I would have liked to have |
Background and motivation
Various pieces of code today allocate new read-only collections (e.g.
ReadOnlyCollection<T>
) around empty collections. Sometimes code implements its own singleton caching, e.g.runtime/src/libraries/System.ComponentModel.Composition/src/System/ComponentModel/Composition/Hosting/CompositionContainer.cs
Line 30 in 58b6828
runtime/src/libraries/System.ComponentModel.Composition/src/System/ComponentModel/Composition/MetadataServices.cs
Line 12 in 58b6828
and sometimes it doesn't, e.g.
runtime/src/libraries/System.Security.Cryptography.Pkcs/src/System/Security/Cryptography/Pkcs/Pkcs12Info.cs
Lines 117 to 120 in 58b6828
runtime/src/libraries/System.Speech/src/Synthesis/VoiceInfo.cs
Line 204 in 58b6828
In other cases, empty could be special-cased but isn't as doing so would have required someone to add their own cache for it to have meaningful benefits).
In any case, we can make this easier and more efficient by exposing our own singletons that we and others can use.
(Replaces #41147, which is limited to just ReadOnlyCollection.)
(Related to #38340, which asked for such Empty methods on mutable collections like
List<T>
returning empty instances of those same collections. There we said we'd consider read-only variants with a proposal; this is that proposal.)API Proposal
API Usage
Alternative Designs
No response
Risks
The text was updated successfully, but these errors were encountered: