I understand that the review period is up (and overall thumbs up to the proposal and it really make sense as a first class thing to support in the standard library rather than a platform-constrained one), but I have a general question applicable to both this proposal but also to the pitch/proposal templates in general;
There is little discussion on performance related concerns (same questions came up with Regex was in progress, Predicates and surely many more) - it's always hard to judge what sort of performance expectations one can have from these super nice abstractions - I understand it can be hard to know exactly, but it'd be helpful I think to just have some discussion around performance and expectations of the implementation as a separate section? It could be scalability considerations/concerns (how does observability cope with many observers? what are the implications in space/time?), what are expected data rates that could be supported? Coalescing overhead? Etc, etc - I'd expect that many of these would be measured and tested during the implementation and it'd be very helpful to get an indication of expected usage envelope (is this implementation expected to mainly be useful for slower data rates updating UI on a mobile device, or is the intention to handle very high data rate server use cases?)
Basically sharing the thought process and experience there - it's easy to say that we get it to work first and fix performance later, but I think it's useful to at least touch on those things also for review?
Maybe it's just me who's interested in it, but wanted to put it out there - we'll build our own internal benchmarks of course to evaluate if/where we can use it when it drops, but maybe it'd be useful to at least share the thought process of the people proposing changes what their expectations of performance (runtime, binary size implications (especially for macro stuff...) and memory footprint at least).
Or am I barking up the wrong tree?