[swift-server-dev] Convert HTTPVersion to struct

[Tanner Nelson]

Unless there is a need to be able to exhaustively switch over all supported
HTTP versions, using an enum seems overly restrictive. Especially when
considering that adding or removing cases from enums is a breaking change
(requires a major version bump). As authors of a general purpose HTTP
package, we should be avoiding unnecessary restrictions wherever possible.

As an aside, Go also uses two integers to represent major and minor.
https://golang.org/pkg/net/http/#Request
On Wed, Jun 14, 2017 at 11:38 Rien via swift-server-dev <
swift-server-dev at swift.org> wrote:

>
> > On 14 Jun 2017, at 12:11, Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > On 14. Jun 2017, at 11:36, Rien via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >>> On 14 Jun 2017, at 11:14, Chris Bailey <BAILEYC at uk.ibm.com> wrote:
> >>>
> >>> One factor is whether you consider the version to be discrete values
> or a structured format for data - I'd argue that we have a structured
> format due to the expectation that future versions of the HTTP spec could
> arrive.
> >>
> >> But do you want your code littered with numerical tests or conceptual
> tests?
> >> Suppose a new version of HTTP does arrive, do you really want to
> manually walk through the code and find all tests on the numerical values?
> >> Or would it be easier to use switch statements on an enum and have all
> missing cases pointed out to you?
> >
> > This is actually a argument *for* using numbers. When using an enum in
> an API makes the same break every time you change it. And that is killer
> for a an API representing a living protocol like HTTP.
> >
> > Also in proper source you would check for: `if major >= 2`, not `==`,
> another advantage of using version _numbers_.
> >
> > In the context of HTTPVersion
>
> Precisely. I am making the argument for enum’s only for the HTTPVersion
> since it is such a unique feature.
>
>
> > I think there shouldn’t be too much discussion though, for two reasons:
> > - If we get HTTP/3.x, we almost certainly have a new API revision.
>
> Absolutely.
>
> > - The HTTP version should only matter for logging purposes. The
> differences in capabilities
> >  should be handled by the implementation (e.g. keep alive vs not,
> multiplexing or not, etc).
>
> Agreed, which is why the decision should be made carefully. An API
> developer usually sees things differently from an API user. Conceptually a
> version number is just a tag. It does not represent a numerical value.
> Which makes testing for numerical values error prone, which leads to your
> following point:
>
> >  In other words, you should never have to check for the versions, but
> rather features.
>
> Again, fully agreed. But which I interpret as an argument in favour of
> enums...
>
> Rien.
>
> >
> > hh
> >
> > _______________________________________________
> > 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/20170614/9df55052/attachment.html>