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.

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

[RDG] Route handlers with the same parameters but differing nullability produce compiler warnings #46622

Closed
captainsafia opened this issue Feb 14, 2023 · 3 comments
Labels
area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc feature-rdg
Milestone

Comments

@captainsafia
Copy link
Member

captainsafia commented Feb 14, 2023

At the moment, it's hard to use our strongly-typed overloads strategy to generate code that correctly handles two route handlers with the same parameters but differing nullability:

app.MapPost("/foo", (Todo todo) => ...);
app.MapPost("/bar", (Todo? todo) => ...);

We might consider generating two different strongly-typed overloads, one with the nullability annotations and one without:

MapPost(System.Action<Todo>);
MapPost(System.Action<Todo?>);

But overload resolution is not able to discern between the two delegate signatures and treats them as ambiguous overloads.

We can also emit only the overload that expects an NRT:

MapPost(System.Action<Todo?>);

But that presents a nullability warning to users (CS8622) when passing an overload to the delegate that does not expect an NRT.

@captainsafia
Copy link
Member Author

Update: this only impacts scenarios where the handler is passed as an inline lambda.

@captainsafia captainsafia added this to the .NET 8 Planning milestone Feb 16, 2023
@ghost
Copy link

ghost commented Feb 16, 2023

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@captainsafia
Copy link
Member Author

Closed via interceptors support.

@ghost ghost locked as resolved and limited conversation to collaborators Aug 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc feature-rdg
Projects
None yet
Development

No branches or pull requests

2 participants