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

Get rid of declareSchemaRef's Proxy argument in favour of TypeApplications #188

Open
23Skidoo opened this issue May 10, 2019 · 5 comments
Open

Comments

@23Skidoo
Copy link

Would be nice if I could write

declareSchemaRef @Username

instead of

declareSchemaRef (Proxy :: Proxy Username)

Any objections? I can probably look into making a patch.

@23Skidoo
Copy link
Author

Main downside of this is that it will mean losing compatibility with GHC < 8.

@jonathanjouty
Copy link

Would this work well with servant-swagger?
In particular, if you only want a sub-part of the API to be part of the Swagger definition.

Would something like this work?

type API = PublicAPI :<|> InternalAPI

mySwagger :: Swagger
mySwagger = toSwagger @InternalAPI

@phadej
Copy link
Collaborator

phadej commented May 10, 2019

@jonathanjouty This change is not related to servant-swagger at all. swagger2 to servant-swagger is like aeson is to servant (exaggerating, but close).

@23Skidoo I'd like to be consistent. What about Data.Swagger.TypeApplications with variants without Proxy argument (and AllowAmbiguousTypes enabled only there). Removing Proxy arguments would break everyone; that's not something I'd like to do. :(

@phadej
Copy link
Collaborator

phadej commented May 10, 2019

Yet, I'd like to remove polymorphic proxy :: to make things DerivingViable.

@23Skidoo
Copy link
Author

What about Data.Swagger.TypeApplications with variants without Proxy argument (and AllowAmbiguousTypes enabled only there). Removing Proxy arguments would break everyone; that's not something I'd like to do. :(

Fine with me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants