System.Collections.Generic.IReadOnlySet<T> is internal in System.Collections.Immutable NuGet package

[AgWillo]

Description

IReadOnlySet<T> is exposed as internal if added to an assembly via the NuGet System.Collections.Immutable package (version 8.0.0+, I believe), but the interface is public in .NET 5+.

Reproduction Steps

1. Create a project that targets, for example, .NET Framewor4 4.6.2 and add the latest version of the System.Collections.Immutable NugetPackage (9.0.6 as of this writing).
2. Attempt to create a variable with a type of, say IReadOnlySet<string>.

Expected behavior

Per the documentation for IReadOnlySet<T> Interface, no error should be reported.

Actual behavior

The compiler raises error CS0122, 'IReadOnlySet<T>' is inaccessible due to its protection level.

Regression?

No response

Known Workarounds

No response

Configuration

This behavior appears with .NET (< 5) and .NET Framework versions that are supported by the System.Collections.Immutable NugetPackage version 9.0.6 (probably any version from 8.0.0 through 9.0.6).

Other information

My use case involves a collection that wraps FrozenSet<T> in a .NET Framework project. I'd like to expose it as IReadOnlySet<T>, but the NuGet package's implementation prevents this.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-collections
See info in area-owners.md if you want to be subscribed.

[stephentoub]

IReadOnlySet<T> is only available on .NET 5+. It is not made available by any System.* package on older versions of .NET. It is not available on .NET Framework. (Some packages may include it as an internal implementation detail of that package, for that package's own internal mechanics, but it is not then made available for others to reference.)

[AgWillo]

Inasmuch as that's essentially a restatement of the problem, should this be (re)submitted as some other type of Issue, e.g., API Suggestion?

[eiriktsarpalis]

We generally don't add new types to older versions of the framework.

[AgWillo]

We generally don't add new types to older versions of the framework.

Certainly, but with FrozenSet (and FrozenDictionary) now working with .NETStandard 2.0 et al, the absence of (a public)IReadOnlySet<T> looked like an oversight, since FrozenSet<T>'s docs say that it implements IReadOnlySet<T>.

Again, if I've mischaracterized this as a bug, I'll resubmit it as something else—or can this issue be converted somehow?

[stephentoub]

I'm not sure if the docs site supports TFM-based inclusion/exclusion of an interface implementation when the type being documented comes from a package like this. @gewarren? If it does, this could be addressed as a documentation issue in https://github.com/dotnet/dotnet-api-docs.

We can't add IReadOnlySet<T> downlevel in a way that would allow for it to be implemented correctly. For example, HashSet<T> on .NET Framework can't implement the interface. And we wouldn't ship IReadOnlySet<T> as a public interface in System.Collections.Immutable as it would conflict with other definitions from other folks.

I appreciate your interest, but this isn't actionable from a code perspective.

[gewarren]

I'm not sure if the docs site supports TFM-based inclusion/exclusion of an interface implementation when the type being documented comes from a package like this. @gewarren? If it does, this could be addressed as a documentation issue in https://github.com/dotnet/dotnet-api-docs.

It does support that and is already correct in that it doesn't show IReadOnlySet<T> as an implemented interface when the selected moniker is .NET Standard 2.0.

[stephentoub]

I'm not sure if the docs site supports TFM-based inclusion/exclusion of an interface implementation when the type being documented comes from a package like this. @gewarren? If it does, this could be addressed as a documentation issue in https://github.com/dotnet/dotnet-api-docs.

It does support that and is already correct in that it doesn't show IReadOnlySet as an implemented interface when the selected moniker is .NET Standard 2.0.

@gewarren, how do I navigate to that? If I select .NET Standard 2.0 or .NET Framework 4.8 from the dropdown, for example, I end up on a page that still shows IReadOnlySet.

[gewarren]

@stephentoub You have to select the moniker that has "package-provided" in its name.

[stephentoub]

I tried that with .NET Framework 4.8 (package provided) and it puts up a message saying I've been redirected to the latest version, which shows IReadOnlySet.

[gewarren]

@stephentoub Thanks for catching that. There are a couple of things going one, one of which I've just fixed, so now you should be able to select .NET Framework 4.6.2 (package-provided) and see that ReadOnlySet<T> doesn't show in the interfaces.

The other thing is that we don't currently "expand out" the .NET Framework target frameworks like we do for .NET...meaning if a package targets .NET Framework 4.6.2, like this one does, it only shows as "applying to" .NET Framework 4.6.2 (package-provided) but not any later .NET Framework versions. I chose to do it that way so as not to clutter the "Applies to" table. But I'm definitely open to feedback and suggestions here, and it probably should be consistent with how we expand out for the .NET package-provided monikers.