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
Help understanding type inference issue for minimal APIs - TypedResults / DynamicallyAccessedMembers #16890
Comments
I think it's just because Your example compiles if you do something like this: open System
open System.Threading.Tasks
open Microsoft.AspNetCore.Builder
open Microsoft.AspNetCore.Http
open Microsoft.AspNetCore.Http.HttpResults
type IndexHandlerResponse = Results<Ok<string>, ProblemHttpResult>
let inline (~~) x = ((^a or ^b) : (static member op_Implicit : ^a -> ^b) x)
[<EntryPoint>]
let main args =
let builder = WebApplication.CreateBuilder(args)
let app = builder.Build()
let maybeTask = task { return Some "Hello world!"}
let indexHandler (): Task<IndexHandlerResponse> =
task {
let! maybe = maybeTask
if maybe.IsSome
then return ~~TypedResults.Ok<string>(maybe.Value)
else return ~~TypedResults.Problem("")
}
app.MapGet("/", Func<Task<IndexHandlerResponse>>(indexHandler)) |> ignore
0 |
In other words, the real problem is that types The error message can get some improvements. Update: Ah, @brianrourkeboll beat me to it. |
I assumed this was what was going on. Your "double-tilde" workaround was exactly the sort of thing I was looking for but lacked the knowledge to define myself - thanks v much :) What I didn't want to do was upcast to I think the "bug" here (if there is one) is around the unanticipated behaviour i.e. it works fine if the If anyone wants to suggest a more apt title for this I'll update the issue :) |
My guess is that the elaboration of the Compare the contents of the generated |
We should improve the error message here, but otherwise this is not a bug, @brianrourkeboll explained it well (thanks!) |
Why is it that the first scenario works as I'm expecting? I'm not protesting the idea that this isn't a bug, as I don't have the knowledge to make a claim either way, just interested to understand as it seems inconsistent to the lay person. Would the suggested guidance for people making a minimal API be to use the method brianrourkeboll suggested? |
I would guess that the compiler automatically inserts calls to In the second scenario, after the (Disclaimer: this is just a guess; I haven't looked at the compiler to see what it actually does.) |
What would it do? leverage the fact that the type defines |
This, as well as choose ranges better for state machines based builders. We probably don't want to include any binds when we can't infer return type |
I have created an F# web project using the minimal APIs approach by running
dotnet new web -lang F#
using dotnet 8.0.I'm trying to get this working using the
TypesResults
class, such that Open API types can be derived without me specifying them using theProduces
method.This works fine for the following scenario. Note the usage of the
Results
type which is required to allow the correct return types for theindexHandler
:However, as soon as I convert this to a real-life example where the
maybe
option is wrapped in a task which gets evaluated in the body of the handler, things stop working due to "Type constraint mismatch" errors:Errors are as follows:
Is this expected behaviour, or am I doing something wrong here? Be good to understand whether there's a known workaround for this.
In terms of a workaround this is the best I can come up with at the moment:
The text was updated successfully, but these errors were encountered: