<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""><div class="">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. </div><div class=""><br class=""></div><div class="">Just an example to show the idea:</div><div class="">…</div><div class="">protocol Request { … }</div><div class=""><br class=""></div><div class="">// add middleware that can mutate the content</div><div class="">func addMutatingMiddleware(middleware: (inout Request) -> ())</div><div class=""><br class=""></div><div class="">// add middleware that cannot mutate the content</div><div class="">// if Request is a class, there’s no way to prevent the middleware from mutating the content</div><div class="">fun addConstMiddleware(middleware: (Request) -> ())</div><div class="">...</div><div class=""><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 27, 2017, at 4:52 AM, Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">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</p><div class=""><br class=""></div></div></blockquote></div></div><div class=""><br class=""></div></div></div></div></div></div></body></html>