[API Proposal]: HttpRequestOptions should implement IReadOnlyDictionary

[Grauenwolf]

Background and motivation

Methods and extension methods that don't modify a dictionary often expect a parameter of IReadOnlyDictionary instead of IDictionary.

API Proposal

namespace System.Net.Http
{
    public class HttpRequestOptions : IReadOnlyDictionary<string,object>, // NEW
                                      IDictionary<string, object> // EXISTING
    {
          [...]
    }
}

API Usage

var dic = (IReadOnlyDictionary<string,object>)request.Options;

Alternative Designs

No response

Risks

In rare circumstances, a method will have an overload for IDictionary and another overload for IReadOnlyDictionary. This would be ambiguous for HttpRequestOptions, as it is for other dictionaries.

[ghost]

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

Issue Details

---

Background and motivation

Methods and extension methods that don't modify a dictionary often expect a parameter of IReadOnlyDictionary instead of IDictionary.

API Proposal

namespace System.Net.Http
{
    public class HttpRequestOptions  : IReadOnlyDictionary<string,object>
    {
          [...]
    }
}

API Usage

var dic = (IReadOnlyDictionary<string,object>)request.Options;

Alternative Designs

No response

Risks

In rare circumstances, a method will have an overload for IDictionary and another overload for IReadOnlyDictionary. This would be ambiguous for HttpRequestOptions, as it is for other dictionaries.

Author:	Grauenwolf
Assignees:	-
Labels:	api-suggestion, area-System.Collections, untriaged
Milestone:	-

[ghost]

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

Issue Details

---

Background and motivation

Methods and extension methods that don't modify a dictionary often expect a parameter of IReadOnlyDictionary instead of IDictionary.

API Proposal

namespace System.Net.Http
{
    public class HttpRequestOptions  : IReadOnlyDictionary<string,object>
    {
          [...]
    }
}

API Usage

var dic = (IReadOnlyDictionary<string,object>)request.Options;

Alternative Designs

No response

Risks

In rare circumstances, a method will have an overload for IDictionary and another overload for IReadOnlyDictionary. This would be ambiguous for HttpRequestOptions, as it is for other dictionaries.

Author:	Grauenwolf
Assignees:	-
Labels:	api-suggestion, area-System.Net.Http, untriaged
Milestone:	-

[karelz]

Triage: IReadOnlyDictionary is strict subset of already implemented IDictionary, so the work is minimal. We wouldn't mind having both interfaces, unless it brings some known problems in general (API review to advise here).
BTW: The type HttpRequestOptions was introduced in .NET 5.

[bartonjs]

Looks good as proposed.

We discussed the risks inherent to being both IDictionary and IReadOnlyDictionary (namely, being an ambiguous target for overloading). But we generally think that the risk is low, and the workaround (casting to one of the two interfaces) is easy.

namespace System.Net.Http
{
    public class HttpRequestOptions :
+        IReadOnlyDictionary<string,object>,
         IDictionary<string, object>
    {
    }
}