StreamController should not be a StreamSink, just an EventSink (the former also implements the StreamConsumer interface with addStream and a close that returns a future which StreamController doesn't actually need).
Provide a specialized StreamSinkAdapter that wraps the controller, but don't make every StreamController have to deal with done futures and addStream state.
Instead of removing the StreamSink from StreamController we are going to allow add calls to StreamControllers while the controller is already executing an addStream.
This has similar benefits.
Was it decided on and still planned to allow add calls to a StreamController when addStream is still executing?
I recently found myself in a situation where I needed the ability to insert a single event to a StreamSink (implemented by StreamController) into which a separate Stream of events had already been piped.
This is simple enough to work around when using streams and sinks directly, but is problematic when using higher level abstractions provided packages such as package:async and package:stream_channel.
I still want to do this, and have a changelist that was originally prepared for Dart 2.0 which was working towards that. I need to backtrack a little on that changelist because some changes planned for Dart 2.0 didn't make the cut. I still hope to get there, but priorities makes it hard to find the time ;)
It's a non-breaking change, so it should be possible.
Thanks for the update!
Most helpful comment
I still want to do this, and have a changelist that was originally prepared for Dart 2.0 which was working towards that. I need to backtrack a little on that changelist because some changes planned for Dart 2.0 didn't make the cut. I still hope to get there, but priorities makes it hard to find the time ;)
It's a non-breaking change, so it should be possible.