HTTP2Frame Payloads as an implicitly @_frozen enum.

[AlanQuatermain]

Even in Swift 5, enums defined outside of the standard library, C headers, and swift overlays will be considered frozen and immutable, meaning that a modification to one will be a semver-major version-breaking change. Our HTTP2Frame.FramePayload type is (still) an enum, and we literally cannot do anything about it without dropping in a C header enumerating the known frame ID values.

There are already two published RFCs that have added new frame types to HTTP2: the ALTSVC frame defined by RFC 7838 § 4 and the ORIGIN frame defined by RFC 8336 § 2. Those are included already (or are going to be included in my encoder/decoder patch), but more will doubtless arrive at some point.

Is there anything we can do about this? My original implementation used a Frame protocol and subtypes, with a switch over the type (i.e. case is DataFrame: or case let x as DataFrame:) to disambiguate them. Is this a better option, and if so, shouldn't we try to land this before swift-nio-http2 transitions off its nghttp2 dependency altogether?

[Lukasa]

I think we absolutely can change this, as the removal of nghttp2 will be a semver major anyway.

The question is what the design should be. My inclination is to avoid a Frame protocol with subtypes, as it necessarily involves a lot of type casting with the runtime performance overhead that entails.

I’m somewhat more interested in the possibility of using an enumeration with an escape hatch for future custom frame types. This would be a .custom case that holds both the frame ID and an Any, allowing a hook for extensions in the future.

That said I’m definitely open to other designs.

[normanmaurer]

Not sure if it matters but we use unkown in netty for custom frame types.