[swift-server-dev] Next HTTP API meeting

[Michael Chiu]

> On Mar 27, 2017, at 5:13 AM, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
> If people feel extremely strong that there needs to be a concrete type, then I'd like to push for reference type as much as possible. As far as reference vs value type, I haven't really heard an argument for value types beyond what feels like a reaction to value types being the hip new hotness. While yes, they're great in Swift, and there's tons of places that should absolutely be modeled with value semantics, a request/response interaction represents a single request and should definitely be a reference based interaction.

I disagree with this one. First of all I think most of the framework pass the request and response as inout argument, if that is the case there shouldn’t be much copy overhead in the run loop. Second the problem of reference type is that everywhere the request and response exists could possibly mutate the res/req, and it affect globally. It is true that in normal use there shouldn’t be two place simultaneously operate on the same request but that could happen. (Therefore protocol is the best isn’t it)

> In practice, we went through several model iterations and the value type created very high levels of bugs and confusion for end users. The three biggest problems we had were as follows:
> 
> - Greatly increased bug levels and confusion related to unexpected mutation
> - Unnecessary code requirements added to every single passive access (ie: middleware) increasing code bloat unnecessarily
> - Extreme performance loss due to massive copy overhead
> 
> Each of these problems evaporated pretty instantaneously when moving to reference types; it made it significantly easier to reason about for end users. 
Just for curiosity, I’m very interested in the unexpected mutation of value semantic, I have always had an impression of value semantic are more free from unexpected mutation. 

> Would like to remind again for those that skipped above reading that our goal is not to build a web framework here, but rather to build small tools that make building frameworks slightly easier for library maintainers and creators. 
That’s so true lol.

Michael.