Content-Length should not be represented as a String as it doesn’t have String semantics. It has the semantic of a single number.
Content-Type should not be represented as a String as it doesn’t have String semantics. It has the semantic of a MIME type.
etc.
My comment was about double standards. If we represent headers as String, method and other stuff can be strings too. As mentioned I’d actually prefer specific types for known headers (not just for typing but also for performance, necessary in practice or not :-) ).
hh
···
On 14 Jun 2017, at 16:50, Samuel Kallner <KALLNER@il.ibm.com> wrote:
HTTPVersion should not be represented as a String as it doesn't have String semantics. It has the semantics of a pair of numbers (i.e. 2.12 > 2.2)
Helge.
I agree with you about the headers and their types. This doesn't mean
there's a double standard. We can still have those headers be strong types.
Only they would be computed properties like so.
But again, headers are not the topic of the current discussion, so let's
keep focus! 
···
On 14 June 2017 at 11:55, Helge Heß via swift-server-dev < swift-server-dev@swift.org> wrote:
On 14 Jun 2017, at 16:50, Samuel Kallner <KALLNER@il.ibm.com> wrote:
> HTTPVersion should not be represented as a String as it doesn't have
String semantics. It has the semantics of a pair of numbers (i.e. 2.12 >
2.2)
Content-Length should not be represented as a String as it doesn’t have
String semantics. It has the semantic of a single number.
Content-Type should not be represented as a String as it doesn’t have
String semantics. It has the semantic of a MIME type.
etc.
My comment was about double standards. If we represent headers as String,
method and other stuff can be strings too. As mentioned I’d actually prefer
specific types for known headers (not just for typing but also for
performance, necessary in practice or not :-) ).
hh
_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev