runtime: #40711 breaks nullable reference types
None of the collection objects support KeyValuePair<string?, string?>, which means the only way that you can use the FormUrlEncodedContent class is by creating a List<KeyValuePair<string?, string?>> object. Is this the intention of the core team?
@ManickaP is wrong in the #40711 statement. An entire year of requiring others to write absurd code is not acceptable. This needs to be escalated to someone higher.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (7 by maintainers)
Thanks for bringing your concerns up! I’ll try to explain what happened there.
This was before nullability for reference types has been introduced, therefore it was equivalent to
string?with nullability checks.This is for us actually quite late in the release cycle since we’re the bottom of the whole stack, we need to freeze all API/feature quite early.
Note that empty/null (depends on your interpretation) keys and/or values are allowed: https://url.spec.whatwg.org/#application/x-www-form-urlencoded.
The original change for 5.0 made non-nullable only keys https://github.com/dotnet/runtime/pull/40267 not values. I’m now considering making both of them non-nullable so that they would be compatible with
Dictionary<string, string>which seems to be the most useful scenario. The only question is whether to introduce a new ctor or remove the nullability completely.This conversation is not different from https://github.com/dotnet/runtime/issues/38494 and https://github.com/dotnet/runtime/issues/44458. If you have any particular suggestions about the API shape, please share them in one of the issues. I don’t see a point in keeping this issue opened and having the discussion split even more.
I have this in my pipeline for 6.0 and it’ll get resolved.