<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="">Hi Dan,</div><div class=""><br class=""></div><div class="">Thanks for spelling out these questions, I think they are a great starting point for a discussion. A few comments inline.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Nov 23, 2016, at 1:19 PM, Dan Appel 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=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">My own responses:</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">>1. Do we want to use concrete types or protocols for Request/Response?</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">When working on <a href="https://github.com/open-swift" class="">Open Swift</a>, this was a hot topic since we believed that it would be unsafe to have a protocol that would allow both value and reference types. </div></div></div></blockquote><div><br class=""></div><div>Bear in mind that a protocol is more than just the methods and types it declares – it is also its documentation. For example, a number of protocols in the standard library state things like complexity requirements in their documenting comments. The language has no way of enforcing these, but your type does not truly “conform” to the protocol unless you adhere to them. Value semantics are similar – you can document that it is invalid to implement a protocol with reference semantics. So I don’t think this is a blocker to wanting to use protocols.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">We arrived upon the `{Request|Response}Representable` pattern which worked but was a bit of a mess. Because of this, I would prefer concrete Request/Response types.</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>You could think of there as being 3 purposes to using protocols here, roughly in order of importance:</div><div><br class=""></div><div><ul class="MailOutline"><li class="">being able to write generic code</li><li class="">allowing different frameworks to interoperate</li><li class="">documenting what you need to implement</li></ul></div><div><br class=""></div><div>The first one is the only reason why a protocol must be included in a library, and the key question to ask when considering defining a protocol like this is “What common algorithms do you want to write across multiple different conforming types in your program”? (such as generic functions, including protocol extensions, or functions that take an existential if the protocol has no associated types).</div><div><br class=""></div><div>This is distinct from wanting to be able to be able to choose from different library implementations of Request. You might want to choose between the Acme Inc Web Framework’s Request type, or some Swift-Server “official" Request type, but you never need to use both at once and write code spanning them. You just want to make sure that one can serve as a source-compatible “drop-in” replacement for the other in your code. This doesn’t mean you can’t write your own extensions – but you would extend the concrete Request not a RequestRepresentable protocol.</div><div><br class=""></div><div>Next, it’s possible that there might be a collection of 3rd-party frameworks out there that don’t define Request, but want to be able to write methods that take or extend multiple possible Request implementations. This seems a bit unlikely in the case of these types, more likely in other cases like networking, so it’s kind of a what-if scenario where there are both multiple popular implementations of Request, and various frameworks that want to interact with them. Anyone can add a conformance to anything, so those frameworks can define a protocol of their own with a subset of the functionality they need, and then just extend the popular implementations to conform to it. If this gets really common, at that point it might be worth creating an official protocol for everyone to share – but this can be done later, doesn’t have to be done up-front. </div><div><br class=""></div><div>Finally, if you do expect multiple implementations and want people to be able to swap them in and out when they choose, the protocol can serve to document what methods and properties you are expected to implement to be “source compatible". This can be done in documentation instead, the benefit of the protocol being it helps the library developer ensure they’ve got all the signatures right etc. But this isn’t something you expose to users, it’s something on the side to help implementors.</div><div><br class=""></div><div>Based on all the above, it seems like there isn’t a pressing need for a protocol for these types right now and initial designs should focus on a concrete implementation until one emerges, if only to avoid premature generalization. Useful protocols tend to be discovered, rather than designed, through a desire to share common operations on different concrete types.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">>2. If we use concrete types, do we want value or reference semantics?</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">What I think makes this easier is that the "big four" have each taken a slightly different approach that can be used as a reference.</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class=""><span style="text-decoration: underline;" class=""><a href="https://github.com/Zewo/Zewo/blob/master/Modules/HTTP/Sources/HTTP/Message/Request.swift#L3" class="">Zewo</a></span> - struct, value semantics</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class=""><span style="text-decoration: underline;" class=""><a href="https://github.com/vapor/engine/blob/master/Sources/HTTP/Models/Request/Request.swift#L4" class="">Vapor</a></span> - closed class, reference semantics</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class=""><span style="text-decoration: underline;" class=""><a href="https://github.com/IBM-Swift/Kitura/blob/master/Sources/Kitura/RouterRequest.swift#L26" class="">Kitura</a></span> - closed class + has-a pattern, reference semantics</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class=""><span style="text-decoration: underline;" class=""><a href="https://github.com/PerfectlySoft/Perfect-HTTP/blob/master/Sources/HTTPRequest.swift#L25" class="">Perfect</a></span> - class protocol, reference semantics</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">Zewo is the outlier here, but I would like to note as a contributor to Zewo that we have not ran into situations where value semantics create an impassable roadblock. </div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">To me, it makes sense to pass them around as values since they don't have any logic of their own. Requests/Responses can't send themselves, they can only read and modified. It also gives me as a user more safety to pass them around since I know that they won't be modified implicitly.</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">Take the following pseudo-code as an example:</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">HTTPServer.onRequest { request in</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class=""> print(request.sourceIp)</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class=""> HTTPClient.send(request)</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class=""> print(request.sourceIp)</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">}</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">With reference semantics, there is no guarantee that sourceIp will be the same before and after sending off the request. After all, it <i class="">could</i> make sense for the HTTPClient to modify the sourceIp before sending off the request. This of course a contrived example, but the point stands.</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Not contrived at all, this is a perfect illustration of why reference semantics make it harder to reason about your code and identify the cause of bugs.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class="">Anyway, I think it would be great if we could have people talk about their own experiences.</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">>3. When is it more convenient to have reference semantics?</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Convenience is a double-edged thing. Pointers with possibly-null values, or integer indexes into Unicode strings, are often considered convenient. But that convenience comes with a hidden cost to correctness – unexpected nulls, accidentally indexing into the middle of a grapheme cluster etc. When making a proper effort to handle these things correctly, code quickly becomes less convenient, and less readable, compared to the alternatives.</div><div><br class=""></div><div>It’s generally the style in Swift that correctness shouldn't be sacrificed for convenience, but when things work out well, convenience and ergonomics can be mutually reinforcing – the code is nice to use correctly, awkward to use incorrectly. For example, optionals that force you to handle nil help with correctness, but they have sugar like ?? or optional chaining to handle common patterns clearly and idiomatically, ! as a shorthand for asserting something is non-nil etc.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">In the middleware chain architecture that we decided on in Zewo (the other ones have something similar), it can be convenient to modify requests in the responder and have that reflect in the middleware. I think this problem is best solved with `inout` parameters rather than reference types, but that is my personal opinion.</div></div></div></blockquote><blockquote type="cite" class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div></div></blockquote><div><br class=""></div><div>FWIW, this design view is also strongly held by those of us working on the Swift Standard Library. I also brought this up with several members of the Core Team and they also strongly felt that <font face="Menlo" class="">inout</font> and value types was the general approach we should take with such types in Swift. The consensus there was that reference types really should be mostly used when identity of the value is important.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">>4. Are there problems that can't be solved with value semantics?</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal;" class="">I haven't found any, but I'm sure others can bring something interesting to the table.</div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="font-family: helvetica; margin: 0px; font-size: 12px; line-height: normal; min-height: 14px;" class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Shared mutable state is one. With an unavoidably-shared resource, like a network connection or a handle to a window on a screen, reference semantics are often what you want.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Nov 23, 2016 at 1:07 PM Dan Appel <<a href="mailto:dan.appel00@gmail.com" class="">dan.appel00@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="gmail_msg"><span class="gmail_msg" style="font-size: 13px;">Hello everyone!</span><div class="gmail_msg" style="font-size: 13px;"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size: 13px;">I was unable to make the kick-off meeting for the HTTP sub-team, but I looked over the <a href="https://docs.google.com/document/d/1SWK0qBDi-9DeLJwHlcXcPU7h22JU-DWW8HTVuHbTQiw/edit" class="gmail_msg" target="_blank">meeting notes</a> and found some topics that I think could use some more on-the-record discussion.</div><div class="gmail_msg" style="font-size: 13px;"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size: 13px;">A few questions that I wanted to raise:</div><div class="gmail_msg" style="font-size: 13px;"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size: 13px;">1. Do we want to use concrete types or protocols for Request/Response?</div><div class="gmail_msg" style="font-size: 13px;">2. If we use concrete types, do we want value or reference semantics?</div><div class="gmail_msg" style="font-size: 13px;">3. When is it more convenient to have reference semantics?</div><div class="gmail_msg" style="font-size: 13px;">4. Are there problems that can't be solved with value semantics?</div><div class="gmail_msg" style="font-size: 13px;"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size: 13px;">I would like to avoid bike-shedding, and I think this can be done by providing real examples rather than just talking about the pros and cons.</div></div><div dir="ltr" class="gmail_msg">--<span class="Apple-converted-space"> </span><br class="gmail_msg"></div><div data-smartmail="gmail_signature" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Dan Appel<br class="gmail_msg"></div></div></div></div></blockquote></div></div><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">--<span class="Apple-converted-space"> </span><br class=""></div><div data-smartmail="gmail_signature" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div dir="ltr" class=""><div class=""><div class="">Dan Appel<br class=""></div></div></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-server-dev mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-server-dev@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">swift-server-dev@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</a></div></blockquote></div><br class=""></body></html>