Please add read-only behavior subject.

[2Xpro-pop]

In PR #1961, this idea was rejected — but I still think it was a great one.
In my own projects, I often end up creating a proxy class like ReadOnlyBehaviorSubject (similar in concept to ReadOnlyCollection).

Introducing a formal interface for this pattern would be a big win for decomposition, encapsulation, and safer design.

[idg10]

We (the current maintainers of Rx.NET) didn't actually reject it. The person who proposed it closed their own PR before we even saw it! (It was only open for 2 days.) It's possible that this was because they felt discouraged by the feedback in that thread (which came from Rx community members, not active maintainers). We never spent much time thinking about this proposal because the proposer had already closed it by the time we got to it.

Had the issue still been open, I would have wanted to better understand the use cases. The proposal came in the form of code without much explanation, which leaves me to try and guess why the author of the PR thought it would be valuable.

As far as I can tell, the basic idea here is that the concept of a reactive read-only property is useful enough that we should consider defining an interface to represent this. The fundamental idea of an IBehaviorObservable<T> is that you can use it in either of two ways:

1. like an ordinary IObservable<T> (i.e., you can subscribe for value change notifications)
2. like an ordinary property (i.e., you can just retrieve the value on demand)

If I'm correctly understanding your statement that it would be:

a big win for decomposition, encapsulation, and safer design

I think (I'm guessing here) the argument would be that people are already exposing properties of type BehaviorSubject directly to achieve this effect, but that this is not ideal because that also provides consumers with the ability to cause it to emit new values. (It's logically equivalent to supplying a read/write property when what you actually want is a read-only property.)

If that's what you're thinking, then I can see the argument that this makes it easier to achieve better encapsulation and safer design. I have been unable to guess what the argument is that this would improve "decomposition".

In fact, composability appears to be the weak point of this design. As was already noted in the feedback on the original PR, as soon as you start using this type's IObservable<T> capabilities by using operators like Select, you effectively erase the fact that it was an IBehaviorObservable<T> because the output of the operator will typically be an IObservable<T>: the 'behavior' part gets stripped off the moment you use it as an observable.

That's not a showstopper. It just means that this type would need to be understood as a kind of 'terminal' type, in the sense that it can only have anything to offer when it is the last (or only) thing in an observable chain.

One question I have is: how much value does this really add? Today you can write something like this:

public class WithObservableProperty
{
    private readonly BehaviourSubject<int> _numbers;

    public IObservable<int> Numbers => _numbers;
    public int CurrentNumber => _numbers.Value;
}

The upside of the IBehaviorObservable<T> is that it simplifies the implementation, specifically by removing 1 line of code:

public class WithObservableProperty
{
    private readonly BehaviourSubject<int> _numbers;

    public IBehaviorObservable<int> Numbers => _numbers;
}

But the consumption model seems slightly clunkier with IBehaviorObservable<T> to me. Here's how it looks consuming the first one:

int currentValue = mySource.CurrentNumber;

and here's how it looks with the proposed IBehaviorObservable<T>:

int currentValue = mySource.Numbers.Value;

So while you've saved yourself a line of code on the implementation side, the consumer side gets slightly more complex. On the other hand, I can see there is some benefit in the fact that the relationship between the event stream and the current value is explicit: it's clear when we retrieve mySource.Numbers.Value that we're using a facet of mySource.Numbers, whereas in the case of mySource.CurrentNumber, the association with the corresponding Numbers property is purely by convention, and may not be obvious.

So here's where I'm at.

I don't agree with the comment on #1961 that said this "makes no sense." That comment seems to be based on the fact that the 'behaviorness' will not propagate through standard Rx operators such as Select and Where. That is true, but I think it misses the point: I think the idea of this abstraction is that it offers two completely different consumption models: you can use it either as an IObservable<T>, or as a normal property. Understood in these terms, I believe the abstraction does make sense. I would meet that comment half way by saying that the 'property-like' aspect of this does not flow through standard Rx operators, and that this may well cause confusion, because there are some situations in which you could reasonably expect that it would. E.g. someone might well expect that mySource.Numbers.Value.Select(int.ToString) would produce an IBehaviorObservable<string>, which it would not.

(Actually, in principle you could define more specialized extension methods so that it did flow like this. But it would only make sense for certain operators. It would not make sense for Where, because that would defeat the expectation that there is necessarily always a current value. What if you wrote mySource.Numbers.Where(x => x > 100), and the initial value is 1? In any case, I don't think it would be justifiable to write a whole second implementation of a load of the standard operators just to support this. Where would it end? What if people want other variations on IObservable<T> to flow in the same way? This doesn't seem sustainable. So in practice, I think we'd just have to accept that the behavior aspect gets erased the moment you use an Rx LINQ operator.)

I also don't think that the comment on #1961 stating that this should be solved at the language level is correct. For one thing, that refers to a proposed part of the extensions feature that 's coming in C# 14 which has, as I understand it, been dropped. (It was a stretch goal.) It wasn't clear to me how that feature would have helped here, but that's academic because the feature ("Adaptation to Interfaces") isn't going to be part of the Extensions feature in C# 14, and isn't going to happen in the foreseeable future.

On the negative side, I'm not yet convinced that the value justifies the addition of a whole new abstraction. (I'm not saying that I'm convinced that the value is not there either. I'm just that I've not seen enough evidence to convince me either way.) Some people have asserted that this would be valuable, but have not supplied strong supporting arguments or evidence.

Also, there is something that troubles me slightly about this. The basic design of Rx builds on simple ideas backed by mathematics. It's easy to use Rx without knowing anything about this, but the mathematical underpinnings are the secret behind Rx's composability. The composition works so effortlessly that we don't often think about it but it's no happy accident: composition is at the very heart of Rx's core abstractions.

From this perspective, IBehaviorObservable<T> feels very inelegant. It is two unrelated concepts being held together by duct tape. You might argue that Rx already crossed that boundary by having BehaviorSubject<T>, but it's notable that this is an implementation, not an abstraction. IObservable<T> and ISubject<T> are abstractions, but BehaviorSubject<T> is not. And arguably it shouldn't be because it doesn't really correspond to anything in the mathematical realm in the way that Rx's other core abstractions do.

Because of this I would expect that IBehaviorObservable<T> wouldn't work as smoothly as IObservable<T> and IObserver<T>. Its failure to flow through operators is a symptom of that, and there would most likely be other problems arising from the relatively weak conceptual integrity.

So while it might be convenient, it's conceptually flaky compare to other Rx abstractions, which makes me wary of it.

That's not a "no". It's a mark against it. It's the reason I would want to see the case in favour providing evidence, and concrete arguments to support the assertions being made in its favour.

[2Xpro-pop]

In my real-world architecture I often need to expose reactive read-only properties from the business logic layer into the MVVM / UI layer.

For example, in my BusinessLogic project I have a service:

public interface IOrderEditService
{
    ValueTask AddShoppingListItem(...);
    ValueTask RemoveShoppingListItem(...);
    ValueTask UpdateShoppingListItem(...);
    ValueTask AddDiscountPolicy(...);
    // ...

    IReadOnlyBehaviorSubject<decimal> TotalPrice { get; }
    IReadOnlyBehaviorSubject<decimal> SubTotalPrice { get; }

    ValueTask<IOrderPaymentService> StartPayment();
}

And in the ViewModel (ReactiveUI):

public class OrderEditPageVm : PageVm
{
      public OrderEditPageVm(IOrderEditService orderEditService)
      {
          this.WhenActivated(disposables => {
              orderEditService.TotalPrice
                   .ObserveOn(RxApp.MainThreadScheduler)
                   .ToPropertyEx(this, x => x.TotalPrice)
                   .DisposeWith(disposables);
                  
              orderEditService.SubTotalPrice 
                   .ObserveOn(RxApp.MainThreadScheduler)
                  .ToPropertyEx(this, x => x.SubTotalPrice )
                  .DisposeWith(disposables);
          });
      }
      
      public extern decimal TotalPrice 
      {
           [ObservableAsProperty]
           get;
      }
      
      public extern decimal SubTotalPrice 
      {
           [ObservableAsProperty]
           get;
      }
}

What abstraction I’m asking for?

A tiny read-only interface that couples “latest value” with “observable of changes” without exposing mutation:

public interface IReadOnlyBehavior<out T> : IObservable<T>
{
    T Value { get; }
}

Extra flexibility (real example)

The read-only interface lets me swap implementations without breaking public APIs. For example, during a payment I want to freeze prices (turn them immutable) while the transaction runs:

// Read-only wrapper over BehaviorSubject<T>
public sealed class ReadOnlyBehaviorAdapter<T> : IReadOnlyBehavior<T>, IDisposable
{
    private readonly BehaviorSubject<T> _inner;

    public ReadOnlyBehaviorAdapter(T initial) => _inner = new BehaviorSubject<T>(initial);

    public T Value => _inner.Value;
    public IDisposable Subscribe(IObserver<T> observer) => _inner.Subscribe(observer);
    public void Dispose() => _inner.Dispose();

    // Internal mutation API stays private to the service
    internal void OnNext(T value) => _inner.OnNext(value);
    internal void OnError(Exception error) => _inner.OnError(error);
    internal void OnCompleted() => _inner.OnCompleted();
}

// Immutable, read-only behavior used to “lock” a value
public sealed class ImmutableBehavior<T> : IReadOnlyBehavior<T>
{
    private readonly T _value;

    public ImmutableBehavior(T value) => _value = value;

    public T Value => _value;

    public IDisposable Subscribe(IObserver<T> observer)
    {
        observer.OnNext(_value);
        observer.OnCompleted();
        return System.Reactive.Disposables.Disposable.Empty;
    }
}

And then in the service:

internal sealed class OrderEditService : IOrderEditService
{

    public IReadOnlyBehavior<decimal> TotalPrice { get; private set; }
    public IReadOnlyBehavior<decimal> SubTotalPrice { get; private set; }

    public async ValueTask<IOrderPaymentService> StartPayment()
    {
        // ... domain logic before payment
        TotalPrice .Dispose();
        SubTotalPrice.Dispose();

        // Freeze the exposed behaviors for the duration of payment
        TotalPrice = new ImmutableBehavior<decimal>(_totalPrice.Value);
        SubTotalPrice = new ImmutableBehavior<decimal>(_subTotalPrice.Value);

        // Swap the exposed read-only implementations without changing the interface
        // (UI keeps working: same type, same semantics.)
        
        // ... run payment, then thaw or replace again as needed
        // (Details elided)
    }
}

Why standardizing the interface helps the ecosystem ?

Today every project reinvents its own read-only behavior wrapper. A single, blessed interface (IReadOnlyBehavior<T> : IObservable<T> { T Value { get; } }) means:

• Shared contracts across libraries (ReactiveUI, DynamicData, app code) instead of adapters.
• A common target for helpers, analyzers, docs, and patterns.
• Room for small, safe optimizations (e.g., First can return Value immediately when the source is an IReadOnlyBehavior<T>).

Small Rx extensions that show flexibility

/// <summary>
/// Creates a cold <see cref="IReadOnlyBehavior{T}"/> adapter around <paramref name="source"/>.
/// <para>
/// Until the first value arrives from <paramref name="source"/>,
/// <see cref="IReadOnlyBehavior{T}.Value"/> returns <paramref name="defaultValue"/> and
/// observers receive that default immediately upon subscription.
/// Once the source produces the first value, it replaces the default and subsequent
/// subscriptions see the latest value.
/// </para>
/// <para>
/// Optimization: if <paramref name="source"/> already implements <see cref="IReadOnlyBehavior{T}"/>,
/// it is returned as is to avoid extra wrapping.
/// </para>
/// <remarks>
/// This is a quick sketch for discussion (non‑production). Just showing example why  IReadOnlyBehavior<T>  will be cool feature
/// </remarks>
/// </summary>
public static IReadOnlyBehavior<T> WithDefaultValue<T>(this IObservable<T> source, T defaultValue)

Real-world evidence

Here’s a screenshot from my production codebase (service layer in Kassa.BusinessLogic), where we had to hand-roll our own AdapterBehaviorSubject<T>. This shows that the need for a read-only behavior abstraction is not hypothetical — teams already reinvent this pattern in real projects.

Boundaries of applicability

Here “boundary type” means a type designed specifically for the boundary between layers of the system, not for universal use throughout all Rx pipelines. IReadOnlyBehavior<T> is intended as the form in which business logic or services expose state outward to the UI/VM layer.

Inside the pipeline you can freely use regular IObservable<T> and LINQ operators. At the boundary, where you care about the combination of “current value + stream of changes”, the interface provides a clear contract, without exposing mutation and without duplicating properties (CurrentX + X).

This makes it similar in spirit to other boundary types such as DTOs in DDD or ReadOnlyObservableCollection<T> in .NET UI frameworks: internally you can structure things however you like, but when you cross the API boundary, you expose a safe, read‑only shape.

This role separation helps address concerns about the “mathematical purity” of Rx: we are not changing the foundations, but only adding a convenient and safe form of exposing state at the API level.

[idg10]

Thanks for the response!

I can see that your application design has got value from this abstraction. But you were able to get that value without needing the definition to live in System.Reactive. So the absence of a shared definition was not a blocker here.

As far as I can tell, the main upside in these cases would have been that you wouldn't have needed to define the interface yourself, and you wouldn't have needed to write an adapter for BehaviorSubject<T>. That's not nothing, but it's a fairly small gain. Can you think of any situations in which you found that you were blocked from achieving something that would have been possible if this abstraction had been defined in System.Reactive?

Since it was possible for you to realise the gains of this abstraction despite the fact that System.Reactive didn't define if for you, it's not obvious that the benefits of a shared definition are all that large. I think there are two key questions here:

1. how common is it for projects to have to duplicate this (fairly small amount of) code?
2. are there any problems that would be solved by have a single, shared definition of this interface?

Regarding 1, you said this:

Today every project reinvents its own read-only behavior wrapper. A single, blessed interface (IReadOnlyBehavior : IObservable { T Value { get; } }) means:

Shared contracts across libraries (ReactiveUI, DynamicData, app code) instead of adapters.

I did search GitHub for IBehaviorObservable, IBehaviorSubject, IReadOnlyBehavior and a few other variations, and it looks like saying that "every project reinvents" this overstates it. In public projects at least, there are a handful of definitions, but it doesn't appear to be all that widespread.

If it were extremely common for people to write their own version of this, then that would certainly support the case for adding it to System.Reactive, but I'm not yet convinced that this is in fact the case.

But 2 is also important: are there scenarios that are blocked today as a result of there being no single, shared definition of this abstraction? Sometimes, a central definition of an abstraction can unlock potential.

But as far as I can see, the examples you gave all worked well despite the absence of a single shared definition. This suggests that the added value from a central definition would be very small here. (It would essentially just enable you to remove the interface definition and one simple adapter class.)

As far as I can tell, ReactiveUI and DynamicData don't introduce interfaces to represent this concept. Are you aware of there being any scenarios they would like to support that would be enabled by a common definition of this abstraction?

In a discussion around this very idea in the Rx slack discussion back in 2023 (prompted by the very PR you link to), one of the RxUI people observed that "RxUI ViewModel properties are all effectively hidden BehaviorSubjects" (although as far as I can see, they don't actually use BehaviorSubject<T> to implement this). So they are already making good use of this basic idea, unencumbered by the lack of a common interface defining the abstraction. That seems quite telling to me: if a library that makes this very concept central to its operation doesn't seem to suffer any problems caused by the absence of a common abstraction for that concept, then what value would the common interface bring? (In fact, in this case, this idea is 'terminal' in the sense I described in my earlier sense: apparently they don't even expose the fact that there's an IObservable<T> in a ViewModel property built with ToProperty, so presumably they wouldn't adopt IReadOnlyBehavior here even if it did exist.)

I get that in theory, a common interface would make it possible to write code that could consume implementations of this from multiple libraries. But I don't yet see any specific scenarios in which this would actually be useful.

You made this suggestion:

Room for small, safe optimizations (e.g., First can return Value immediately when the source is an IReadOnlyBehavior).

This actually highlights my concerns about the soundness of the abstraction. You perceive this as a "safe" optimization, but my first thought is that this defeats an important expectation that observable sources can normally rely on: Subscribe operations normally pass through operators to the source. It's quite common to use subscription as the trigger to begin some work. It's how a source knows that somebody is now listening. This is fundamental to the operation of certain Rx features such as RefCount and Defer.

So it's only safe if all implementors of this new interface understand that they can no longer rely on being treated as first class IObservable<T> implementations. My feeling is that the more non-obvious stuff you have like this that you just have to know to code things correctly, the less safe a library is. Uniformity and consistency is currently one of Rx's strengths.

I would be uncomfortable about an essential LINQ operator changing something quite so fundamental for certain particular kinds of observables. It does suggest that this abstraction isn't really an IObservable<T>, because certain things that IObservables<T> can always depend on would no longer apply.

Obviously this has all been on the negative side, but to clarify, this still isn't a "no". One thing could reverse my position: a compelling practical example showing something that can be achieved if and only if this abstraction is shared. (It would need to be compelling enough to overcome my concerns about implementors not enjoying standard IObservable<T> handling though.)