[swift-server-dev] Next HTTP API meeting

[Logan Wright]

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.

- Logan

On Mon, Mar 27, 2017 at 3:01 PM Paulo Faria via swift-server-dev <
swift-server-dev at swift.org> wrote:

> Saying that most people expect an HTTP request/response to be a reference
> type is a claim that needs some numbers to back it up. I'm an evidence of a
> person that expects them to be value types. I didn't count how many in this
> thread expressed positive feelings about value types over reference types,
> but I get the general feeling that most people are favoring value types.
> Even if that's the case, "most people expect request/response to be a value
> type", that's not the best reason to do it so. We should choose the best
> semantics in a technical sense not just because people expect it. After we
> do that, people will know which semantics the types follow because we will
> document it. Then there won't be any confusion about which semantics is
> being used.
>
> On Mon, Mar 27, 2017, 10:31 Tanner Nelson via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
> Re: performance,
>
> I did a quick test of inout struct vs. class performance. The code can be
> found here: https://github.com/tanner0101/request-types
>
> I found only a marginal increase in performance (~5%) in favor of inout
> value types. https://github.com/tanner0101/request-types/issues/1
>
> 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`)
>
> Please feel free to submit any prs/issues/comments about ways I could
> improve this test to make it more accurate.
>
> tl;dr: value types don't seem much faster than reference types (especially
> considering dangers of misuse) in a simulated web framework scenario
>
> inb4: people saying that the request/response models in my test are
> incomplete/not fully implemented/bad. this is _not_ a proposed api for
> request/response.
>
> Vapor
> tanner at vapor.codes
>
> On Mar 27, 2017, at 1:55 PM, Michael Chiu via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
>
> 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.
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170327/f9e2c529/attachment.html>