Repository navigation
[API Proposal]: HttpRequestOptions should implement IReadOnlyDictionary #68149
Description
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.
Activity
karelz commentedon Apr 21, 2022
Triage:
IReadOnlyDictionaryis strict subset of already implementedIDictionary, 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
HttpRequestOptionswas introduced in .NET 5.bartonjs commentedon May 11, 2023
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> { } }Added IReadOnlyDictionary to HttpRequestOptions
Added IReadOnlyDictionary to HttpRequestOptions (#86983)