[swift-server-dev] Convert HTTPVersion to struct

[Rien]

> On 14 Jun 2017, at 13:29, Tanner Nelson <tanner at vapor.codes> wrote:
> 
> 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).

I presume that supporting a new HTTP version will always require a major version bump.

Rien.


> 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