Reactive: Why don't you have safe observers for subjects?

[Sathyaish]

While all Producer<T>'s cast the anonymous observers they receive to safe observers or safe anonymous observers, why don't you have safe observers for subjects?

[bartdesmet]

Mostly for performance because a subject is often used as a multicast block, e.g. within operators like Publish. The rationale is that a subject is transparent and inherits all the sins of the publisher (i.e. the user of the observer side of the subject). Any safeguarding should happen there: because it's an observer, one should use it conform the grammar (or use Observer.* methods to wrap it with safe-guarding or synchronization logic in case it's to be passed to an untrusted party, i.e. this safety is pay-for-play). Note that operators rely on the input(s) being conform the observer grammar and - if this condition is met - guarantee that they will only produce output conform to the observer grammar. That's where we put in safeguarding if an input is not "trusted".

[LeeCampbell]

As I remember it, waaay back in v1 days (2010/2011) everything was safe. However it meant that even if you wrote safe code, you had to pay the cost of all the safety checks in Rx.
Thankfully this has been relaxed, so you can opt-in to safety if a source isnt' trustworthy using features like .Synchroinze(). Due to these design choices Rx performs much faster :-)

[Sathyaish]

Thanks, @bartdesmet and @LeeCampbell. :-)

Thanks for closing this, @onovotny, and sorry about having left it open for so long.

I started doing things other than Rx in the meantime and so I hadn't had a chance to think more about this since @bartdesmet and @LeeCampbell posted their answers and so I left them open on purpose. I realize now that I can still keep thinking about these issues even later. :-)