[API breaking] Add types to inbound/outbound debug handlers

[Davidde94]

Add generic types to inbound and outbound debug handlers. The current implementation is API-breaking, however it's entirely possible to implement in a "minor-version" way (detail below).

Motivation:

I've found that the provided debug handlers are not massively useful without types, as it's not possible (as far as I'm aware) to unwrap the data inside NIOAny outside of a channel handler. This means that to debug-print data inside my application I have to essentially recreate the logic provided by the print handlers. This seems redundant, and it would be nice to have an "official" implementation.

Modifications:

Add generic types T to both Inbound and DebugOutboundEventsHandler. Inside the read event, instead of passing down a NIOAny, pass the unwrapped data.

Result:

[After your change, what will change.]

Notes:

This is an API-breaking change. It's also possible to create new classes, e.g. TypedDebugInboundEventsHandler, etc. Alternatively we could cleverly expose something from NIOAny to allow unwrapping outside of a ChannelHandler. E.g. nioAny.unwrap(as: T).

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[Davidde94]

@swift-server-bot test this please

[weissi]

Yeah, it should’ve been data(Any) not NIOAny... we can also make it fully typed but either solution is API breaking so will probably need to wait until NIO 3 (NIOExtras 2)

[weissi]

@swift-nio-bot add to whitelist

[weissi]

@swift-server-bot test this please

[Davidde94]

@weissi as a short-term win, what do you think of implementing a similar but typed TypedDebugInboundPrintHandler for use now?

[glbrntt]

Are we explicitly opposed to having a public unwrap(as:) method for NIOAny?

[weissi]

Are we explicitly opposed to having a public unwrap(as:) method for NIOAny?

Yes. It’s deliberately opaque and allowing manual unwrapping doesn’t really enable anything that you couldn’t achieve today. Set your InboundIn to Any, then you have self.unwrapInboundIn to Any and from there to anywhere

[Davidde94]

IMO something doesn't feel quite right about using Any, personally I would say fully-typed is generally better as it allows for less misuse

[weissi]

@Davidde94 this handler doesn’t have type information so typing it is impossible (without changing its type). It was designed to handle Any but by accident saved a NIOAny in the Event enum, we just missed this on review

[Lukasa]

Updated this PR to target main.