Replies: 1 comment
-
My suspicion is that you don't want to tie particular responses to your routes - routing is defined as a parser/printer from How the response is parsed is an entirely separate system and really needs a second parser/printer model of The problem then is that with those two functions, you can go from |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
First of all, thank you for putting out this amazing library along with vapor-routing. I think both are filling very important gaps in the problem space in a very elegant way.
After tour episode 4, I was keen to see how typed responses would come into play when synthesizing the API client. I was delighted to see the request part being completely type-safe in such an effortless manner, but I was also slightly disappointed to see response types weren't tied to each specific route, and were instead left to be specified by type along with the request route.
With a struct based approach, this would be fairly trivial to solve. But as I understand there are limitations in the language that make tying static types to enum cases pretty much impossible, and I reckon the exhaustivity of enums is a worthy trade-off to afford this loss of type safety vs structs.
My question is: is there any way to work around this? And even further, is there a language feature that could realistically be conceived that would allow us to solve this issue?
Beta Was this translation helpful? Give feedback.
All reactions