feat(unboxed_closures): allow unboxed closures for handlers and error handlers #197
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a bit of a compromise, allowing unboxed closures to be used for handlers but not for
Middleware
, while also making the routing a bit less flexible for the moment (can only take unboxed closures and not aMiddleware
, so you can't have aRouter
dispatch to anotherMiddleware
without wrapping a closure).The second commit shows an alternative that I encountered while refactoring. If we deem macros acceptable in the time being we could follow that approach, as we maintain flexibility with only a minor syntactic wart. I favor this approach, but wanted to show how the example usage could look without any macros, which is the current state of the PR. Whenever rust-lang/rust#24680 is fixed, we should then be able to depreciate the macro and the user code should be very easy to update
middleware! { |req, res| "foo" }
becomes|_, res| res.send("foo")
.Another alternative is to use
Fn(..)
as the bound everywhere in future when implementing unboxed closures for a type becomes stable, then theMiddleware
trait will become redundant and we could implementFn(..)
forRouter
and such. This approach doesn't help us with the current 1.0 feature-set though.