Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Annotate Microsoft.AspNetCore.Http with nullable attributes #22928

Merged
2 commits merged into from
Jun 15, 2020
Merged

Annotate Microsoft.AspNetCore.Http with nullable attributes #22928

2 commits merged into from
Jun 15, 2020

Conversation

pranavkm
Copy link
Contributor

@pranavkm pranavkm commented Jun 14, 2020 •
edited
Loading

Contributes to #5680

@pranavkm pranavkm linked an issue Jun 14, 2020 that may be closed by this pull request
Update ASP.NET Core to use C# 8's nullable reference types #5680
Closed
@pranavkm pranavkm force-pushed the prkrishn/nullable-http branch 2 times, most recently from d0183ca to a7b27bd Compare June 14, 2020 14:03
@pranavkm pranavkm marked this pull request as ready for review June 14, 2020 16:23
@pranavkm pranavkm added api-ready-for-review API is ready for formal API review - https://github.com/dotnet/apireviews auto-merge labels Jun 14, 2020
@ghost
Copy link

ghost commented Jun 14, 2020

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

  • The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
  • The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
  • Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

@ghost
Copy link

ghost commented Jun 14, 2020

Hello @pranavkm!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@pranavkm pranavkm requested a review from JamesNK June 14, 2020 21:36
Tratcher
Tratcher approved these changes Jun 15, 2020
View reviewed changes
src/Http/Http.Abstractions/src/HttpContext.cs
@@ -68,7 +68,7 @@ public abstract class HttpContext
/// <summary>
/// Gets or sets the object used to manage user session data for this request.
/// </summary>
public abstract ISession? Session { get; set; }
public abstract ISession Session { get; set; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

? Nothing prevents Session from returning null.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the feature throws if it hasn't been set up.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DefaultHttpContext throws if the feature is missing, but it doesn't ensure anything about the actual ISession value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess. But that's true of nearly all of the features, no? We don't verify that the feature has been configured weirdly. In theory, most features could be implemented to return null values, but it would be incredibly cumbersome to use these APIs if they were all marked as nullable. In the ordinary case, it's either non-null or throws, no?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to apply some pragmatism with nullable attributes.

Yes something could technically be null if an app was setup to do an unusual thing, but I think we need to focus on the 99% usage.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The question is if these annotations are trying to communicate "SHOULD NOT" or "MUST NOT" be null (RFC terms). If we stick with marking the common nullable cases that should help people avoid common mistakes.

If we find later we're too loose or too strict with these annotations, how breaking is it to change them? Doesn't it introduce new warnings either way?

src/Http/Http/src/HeaderDictionary.cs
@@ -93,7 +95,7 @@ private void EnsureStore(int capacity)
/// <returns></returns>
StringValues IDictionary<string, StringValues>.this[string key]
{
get { return Store[key]; }
get { return this[key]; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, this was an actual bug.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unit test?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I suppose I should add one.

@ghost ghost merged commit 8efcca4 into master Jun 15, 2020
@ghost ghost deleted the prkrishn/nullable-http branch June 15, 2020 23:29
@pranavkm pranavkm added this to the 5.0.0-preview7 milestone Jun 16, 2020
@pranavkm pranavkm removed the api-ready-for-review API is ready for formal API review - https://github.com/dotnet/apireviews label Mar 22, 2021
@amcasey amcasey added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed area-runtime labels Aug 24, 2023
@ccurrens ccurrens mentioned this pull request Nov 24, 2023
Merged
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Tratcher Tratcher Tratcher approved these changes

@jkotalik jkotalik Awaiting requested review from jkotalik

@JamesNK JamesNK Awaiting requested review from JamesNK

Assignees
No one assigned
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Projects
None yet
Milestone
5.0.0-preview7
Development

Successfully merging this pull request may close these issues.

Update ASP.NET Core to use C# 8's nullable reference types
5 participants
@pranavkm @JamesNK @Tratcher @Pilchie @amcasey