Make middlewares work with result builders

[czechboy0]

The existing prototype in the Middleware module doesn't yet work correctly, this issue tracks being able to write something like:

try await server.serve(
  handler: terminalHandler
) {
  LoggingMiddleware()
  MetricsMiddleware()
  if authEnabled {
    AuthMiddleware()
  }
}

[FranzBusch]

I prototyped this more and I think the core problem is this: with a flat result builder like in your example above the generic middleware types don't infer. LoggingMiddleware() fails with "generic parameter 'Value' could not be inferred". Even when creating a custom "enclosing stack" that pins the generic types.

The reason is that only buildExpression requirements reach the element expression. Requirements on buildBlock or buildPartialBlock never impact the inference into the elements, so the First.ValueOut == Second.ValueIn chaining constraint doesn't work.

To make the flat spelling work, the builder has to be generic over the value type and pin it in buildExpression:

@resultBuilder
struct MiddlewareBuilder<Value> {
  static func buildExpression<M: Middleware>(_ m: M) -> M where M.ValueIn == Value, M.ValueOut == Value { m }
}

With that, the example from the issue compiles with no generic arguments written at the call site. However, the limitation is that buildExpression applies to every element, so it constrains a single type for the whole builder. Middleware that changes the value type then don't work. I do think we need to support this though since we expect middleware to change reader/writer types to offer the custom wrapping.

As far as I can see, there are two options that could work. Method chaining with .then(...) or nesting each middleware's downstream in its own builder. The latter would look like this then:

try await server.serve(
  handler: terminalHandler
) {
  LoggingMiddleware {
    MetricsMiddleware {
      if authEnabled {
        AuthMiddleware()
      }
    }
  }
}

[czechboy0]

From these two options, I guess the closure nesting is better as it allows natural if/switch expressions, which are important to support as well. It visually represents the middleware flow as well, kind of, so it's not the worst idea.

Do you have a branch with the nesting approach that otherwise works overall?

[FranzBusch]

I also prefer that one and no I don't have a branch right now since I mostly prototyped this in a small isolated project.