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. <br><br>As an aside, Go also uses two integers to represent major and minor. <a href="https://golang.org/pkg/net/http/#Request">https://golang.org/pkg/net/http/#Request</a><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 14, 2017 at 11:38 Rien via swift-server-dev <<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 14 Jun 2017, at 12:11, Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>> wrote:<br>
><br>
> On 14. Jun 2017, at 11:36, Rien via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>> wrote:<br>
>>> On 14 Jun 2017, at 11:14, Chris Bailey <<a href="mailto:BAILEYC@uk.ibm.com" target="_blank">BAILEYC@uk.ibm.com</a>> wrote:<br>
>>><br>
>>> 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.<br>
>><br>
>> But do you want your code littered with numerical tests or conceptual tests?<br>
>> 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?<br>
>> Or would it be easier to use switch statements on an enum and have all missing cases pointed out to you?<br>
><br>
> 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.<br>
><br>
> Also in proper source you would check for: `if major >= 2`, not `==`, another advantage of using version _numbers_.<br>
><br>
> In the context of HTTPVersion<br>
<br>
Precisely. I am making the argument for enum’s only for the HTTPVersion since it is such a unique feature.<br>
<br>
<br>
> I think there shouldn’t be too much discussion though, for two reasons:<br>
> - If we get HTTP/3.x, we almost certainly have a new API revision.<br>
<br>
Absolutely.<br>
<br>
> - The HTTP version should only matter for logging purposes. The differences in capabilities<br>
> should be handled by the implementation (e.g. keep alive vs not, multiplexing or not, etc).<br>
<br>
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:<br>
<br>
> In other words, you should never have to check for the versions, but rather features.<br>
<br>
Again, fully agreed. But which I interpret as an argument in favour of enums...<br>
<br>
Rien.<br>
<br>
><br>
> hh<br>
><br>
> _______________________________________________<br>
> swift-server-dev mailing list<br>
> <a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br>
<br>
_______________________________________________<br>
swift-server-dev mailing list<br>
<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br>
</blockquote></div>