<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=""><div class="">Personally I always prefer protocol over value/reference type because I do think it enable end users to write safer code and increase the freedom of the use of the framework.<br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Mar 27, 2017, at 7:08 AM, Logan Wright <<a href="mailto:logan@qutheory.io" class="">logan@qutheory.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">For expectations, my comments about it are mostly gathered from conversations and bug help and question answering from users greatly confused by value types. Unfortunately, many of these conversations are lost to the free plan associated with slack. Aside from expectations (which as Paolo pointed out could use more evidence) reference types provide more performance, reduce bugs, and reduce code overhead which seem like pretty good reasons to me. I think a good question is, can anyone propose a use case where one would want to mutate a request without reflecting those changes to subsequent responder chains? Right now, that seems to be the only pro that value types propose since there's no other tangible advantage that I can see.<br class=""><br class="">- Logan</div></div></blockquote><div><br class=""></div><div>Just a quick example for 2 value type use case .<div class=""><br class=""></div><div class="">Case 1) able to reuse static, pre-constructed response</div><div class=""><br class=""></div><div class="">// static </div><div class="">let httpDefaultErrorResponse = HTTPRespone(status: 404, headers: […omit…], body: nil)</div><div class=""><br class=""></div><div class="">func response_to_some_request(req: HTTPRequest, res: inout HTTPResponse) {</div><div class="">… omit code ..</div><div class="">If resource.notFound {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>res = httpDefaultErrorResponse.appendBody(“\(resources.uri) not found”)</div><div class="">}</div><div class="">… omit ...</div><div class="">}</div><div class=""><br class=""></div><div class="">Case 2) a simple server receive response from 1 end point and forward to different clients with appended header.</div><div class=""><br class=""></div><div class="">…omit...</div><div class="">var common_response = my_discrete_computing_server.makeCommonResponse(from: discrete_computing_request )</div><div class="">pool.clients.forEach {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>client.send(common_response.appendHeader($0.workerId, for: “worker-id”)</div><div class="">}</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_msg" style="word-wrap: break-word;"><div dir="ltr" class="gmail_msg">On Mon, Mar 27, 2017, 10:31 Tanner Nelson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_msg" style="word-wrap: break-word;"><br class=""><div class="gmail_msg">I did a quick test of inout struct vs. class performance. The code can be found here: <a href="https://github.com/tanner0101/request-types" class="gmail_msg" target="_blank">https://github.com/tanner0101/request-types</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I found only a marginal increase in performance (~5%) in favor of inout value types. <a href="https://github.com/tanner0101/request-types/issues/1" class="gmail_msg" target="_blank">https://github.com/tanner0101/request-types/issues/1</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Additionally, non-inout value types were a lot slower. This is obvious to the seasoned Swift dev considering each middleware in the test modifies and thus must copy the request. But this is the exact type of performance issue you can expect developers to create when interacting with "non-obvious value types". HTTP request/response being non-obvious value types compared to something like an integer or a float. (I'd argue the majority of web developers would expect request/response to be a reference type and thus easily forget or not know to use `inout`)</div></div></blockquote></div></blockquote></div></blockquote></div></blockquote><br class="">Thanks so much for the benchmark result, this is definitely a helpful reference for future discussion. The thing I concern is, the performance of reference type is likely going to decrease proportion to the number of connections due to heap allocation.</div></div><div class=""><br class=""></div><div class="">Michael</div></div></div><br class=""></div></body></html>