Hi all, thanks for such a great library. I was wondering something about

Typesafe RequestContexts

. In certain level, it makes extraction type safe however it does not guarantee that we won't forget to populate context with data. Isn't there a better approach to handle this situation?

it's the best we've come up with so far. I suppose the question is what kind of behaviour would you expect that's different from what we have now? Unfortunately we can't use typesafety for the HttpHandler stack because of the consistent interface (unlike, for instance Finagle which changes the type of the request going through the stack as you populate it)

Hey, David, thanks for your answer. I am actually coming from Scala and it's quite common in Scala web frameworks/libraries that you can change the request type which solves the issue I mentioned above.

I suppose the question is what kind of behaviour would you expect that's different from what we have now?

I think I would love to have the extracted context to be available in type safe manner and I expect compiler to check whenever I forgot to provide the expected context. For example, if I failed to provide filter that was suppose to put variable to context, compiler wont help me there and it will fail at runtime regardless of the request. (Anyone with decent test coverage would find this before it become bug of course) Anyway, I think I was more interested in why http4k did not chose to go that way. Was it because missing feature in the language or was it because design choose etc. Regardless, I still love the functional approach http4k brings. Thanks for all the effort!

yeah - since we're pinned to the typealias we can't change the type. But if you wanted to you could easily create a an inner "typed pipeline" which used: 1. a typed handler interface/typealias (with custom Req/Resp) 2. conversion methods to convert to/from http4k Req/Resp.