<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="">I think we’re going around circles in the mailing list on type vs semantic. I personally prefer to have a protocol interface and also a default concrete type, for the concrete type I’ll prefer value type but reference semantic or hybrid implementation. <div class=""><br class=""><div class="">As discussed in the second meeting, value type != value semantic and reference type != reference semantic.<br class=""><div class=""><a href="https://github.com/swift-server/work-group/blob/master/meetings/http/2016-12-12/minutes.md" class="">https://github.com/swift-server/work-group/blob/master/meetings/http/2016-12-12/minutes.md</a></div><div class=""><br class=""></div><div class=""><div class=""> </div><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div><div class="">It’s very simple.</div><div class="">You want to retrieve data for the response from external service ( for example Redis ) asynchronously. ( Asynchronously because you don’t want to block request handlers just to wait for the data ).</div><div class=""><div class="">You cannot do it if Request and Response were structs. You cannot retain them inside Redis-callback closures.</div></div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes in this case inout won’t work for obvious reason but you can actually retain them in the callback closure as long as it has some class member, we can always write getters and setters. In fact making the it value type we can leverage inout argument to reduce the overhead of ARC since inout captures the struct in the stack.</div><div class=""><br class=""></div>In fact, making the req/res value type make it safer from accidental mutations. In order to mutate the struct in the callback closure, end user will have to do something like { var res = $0 } in the closure, and the mutating and nonmutating keywords can only use on value types. (And it comes for free in swift, no external protocol needed) </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">How do you suggest to allocate struct on the heap? using UnsafePointers ? and how is that any better than using class if you want to achieve Reference semantics ?</div></div></div></blockquote><div class="">If personally I’m building a framework, I’ll always prefer UnsafePointer of heap allocate structs to achieve reference semantics, with maybe some Unmanaged for classes. But the goal we’ve now is to build utilities for building frameworks. </div><div class=""><br class=""></div><div class="">UnsafeMutablePointers<struct> has the following benefits over class and Unmanaged<class>:</div><div class="">- no ARC // with Unmanaged you still have to manage the counting yourself</div><div class="">- able to use third party allocator</div><div class="">- Maybe even external garbage collector</div><div class="">- C/C++ data structure friendly</div><div class=""><br class=""></div></div><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">I believe issues related to using structs mentioned by Logan were similar to your example:</div><div class=""><br class=""></div><div class="">fun addConstMiddleware(middleware: (Request) -> ())</div><div class=""><br class=""></div><div class="">Here, if request is a struct, it will be copied for each middleware, and instead of one ARC increment we will need to copy the request itself + increment all the reference counts for its properties.</div><div class=""><br class=""></div><div class="">Now, if it was a class and we wanted to create a read-only function for that, we could easily create a protocol that has only { get } access to properties,</div><div class=""><br class=""></div><div class="">protocol ImmutableRequest {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>var headers: … { get }</div><div class="">}</div><div class=""><br class=""></div><div class="">Request: ImmutableRequest </div><div class=""><br class=""></div><div class=""><div class="">fun addConstMiddleware(middleware: (ImmutableRequest) -> ())</div><div class=""><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">It depends on the semantic. If the struct is a reference semantically designed it has only the size of a few pointers, which is much less expensive than the ARC overhead.</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">As I see from these emails, one of the main reasons for using struct is to avoid ARC overhead and this can be understood. Still we want to use struct but at the same time want all the functions ( responder chain ) to be able to change it. That sounds like a Reference semantic to me.</div><div class=""><br class=""></div></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">If we can prove that ARC overhead is significant and there is no way to optimise it, probably the good way would be to use structs. Then, frameworks like Kitura/Perfect… can wrap the struct in a class and pass it to a responder chain.</div></div></blockquote><br class=""></div><div class="">Actually if we really do want to avoid ARC overhead on classes we can use Unmanaged<class> as well. Wrap the struct in a class is basically identical to class so it doesn’t make too much sense to me. </div><br class=""></div></div></div></div><div class=""><br class=""></div><div class="">Michael.</div></div></body></html>