[swift-server-dev] Next HTTP API meeting

[Michael Chiu]

If we have to go for concrete type, I will go for value type. But I’m not quite understand how the value/reference duality of protocol will led to bugs, in fact I think protocol implementation should be much safer because it explicitly mark if a member or method is mutating or not.

For the concern of middleware, I believe the most efficient and the best way is to pass the req/res as inout argument, this should make no much difference between passing a protocol/struct/class, even better, if  the middleware does not require mutability of the res/req, for example a statistics middleware, we can simply not make the argument inout to prevent accidental mutation. In the end, It results a much safer api. 

Just an example to show the idea:
…
protocol Request { … }

// add middleware that can mutate the content
func addMutatingMiddleware(middleware: (inout Request) -> ())

// add middleware that cannot mutate the content
// if Request is a class, there’s no way to prevent the middleware from mutating the content
fun addConstMiddleware(middleware: (Request) -> ())
...

> On Mar 27, 2017, at 4:52 AM, Paulo Faria via swift-server-dev <swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>> wrote:
> 
> using a protocol for the HTTP request/response is not the best option because of the value type/reference type duality. People implementing an HTTP middleware, for example, would have to decide themselves which type semantics they're expecting the underlying implementation to provide. This means that code written with one semantics in mind would present bugs if used with an implementation that uses the other implementation. Of course we could restrict the protocol to reference types by making it a class protocol, but if we're doing that we might as well just go with classes. So the best solution is to go with concrete types. I prefer value type semantics, and to be honest, after reading the memory ownership manifesto, maybe move semantics would be the best option for HTTP request/response, but since we don't have it yet, I think we should go with value types for now
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170327/f1e4747a/attachment.html>