A good change…would you mind applying this to the other drain emits (and full-drain) as well please?

Will do! There's other (ie, non-drain) events there that also don't pass the stream. I figure it should be done across all of the stream types since the event signature is more or less part of the interface. Is that reasonable?

@jmalloc since this is a bit more of a fundamental change, can you look at all the events, post a small summary and assess whether passing stream everywhere would make sense?

Sure, here are each of the event signatures as they are currently:

Given how easy it is to use a closure as a handler obviously it's not imperative that the stream be passed on every event, but I can't think of any downside. At the very least close, data and error, which have multiple signatures currently, should have matching signatures across implementations.

pipe might be the one event where passing the stream doesn't make much sense as currently only the emitters of this event are listening to themselves, which I think is a product of the logic for piping being implemented in Util. At any rate I can't think of a strong argument for not passing the stream.

All of the streams mentioned in the table above now have consistent event parameters.

While I was doing this I realised there's a few stream implementations in other namespaces (HTTP requests/responses, etc) that are a bit different again, some of those events introduce new parameters entirely so I don't think I'll attempt to address that in this PR.

👍

@igorw, @nrk good?

Merged.