@kzaher : Thanks a lot 👍

@kzaher one pain point migrating Variable to BehaviorRelay was that value is read-only, this disallows in-place mutation of the value - especially if the value is some kind of a collection. This requires a workaround like:

var mutableCopy = relay.value
mutableCopy.mutateSomehow()
relay.accept(mutableCopy)

@DevAndArtist

var mutableCopy = relay.value
mutableCopy.mutateSomehow()
relay.accept(mutableCopy)

this is a dangerous patten because after you read relay.value a new value could be set before you call relay.accept(mutableCopy) and thus you could accidentally overwrite something.

I am assuming people were doing this a lot, and because of Swift accessor semantics these issues where hidden, but I would say this is an anti-pattern for the mentioned reasons.

That's why we haven't made Variable deprecated yet. Even though I know it's theoretically correct thing to do, people have a lot of faulty existing code that works for them because of some implicit assumptions.

For example, if you assume all code is executed on main thread, then this can't happen

this is a dangerous patten because after you read relay.value a new value could be set before you call relay.accept(mutableCopy) and thus you could accidentally overwrite something.

But there is nothing in the API that prevents it.

We'll probably at least move Variable to RxCocoa in the next major version as a good first step.

@kzaher even if it's a dangerous pattern in a multi-thread context, how would I append a new item to the value if for instance it was BehaviorRelay<[Int]>? What would be correct way to do so? I mean isn't that why we need a thread safe value { get set } for in-place mutation?

@kzaher and @DevAndArtist : I had exact same issue which I had posted in SO. https://stackoverflow.com/questions/47452582/how-to-use-behaviorrelay-as-an-alternate-to-variable-in-rxswift

One solution proposed by community was to use BehaviorSubject but that defeats the purpose. BehaviorRelay is an alternate to Variable and Variable's value property was mutable now that BehaviorRelay has read only value. I ended up using accept as below

    let relay = BehaviorRelay(value: [10])
   //When I need to update my relay with new value
    let array = relay.value
    let newArray = Array(Set(array + [20,30]))
    relay.accept(newArray)

Though it works, I dont think this is the best way to use it. I am sure many are facing this confusion. Please add a sample usage of BehaviorRelay to clarify all our doubts.

With this change, does BehaviorRelay have to be in RxCocoa? When using this in layers beyond the view (e.g., Presenter/MVVM/Model layers), the best practice is to not include UI imports, but RxCocoa has a lot of UI aspects. Variable was a simple to use piece, that only required RxSwift, but BehaviorRelay breaks that paradigm in it's current library.

@Herbal7ea The problem is Variable in itself isn't part of RxSwift or ReactiveX. It is a Cocoa-specific implementation that mainly works as an Imperative Bridge to people that find it hard to go "All declarative / all observable" immediately. It is not really a pure component of RxSwift to begin with 🤔

@Herbal7ea

If we extract *Relay and SharedSequence into their own frameworks in the next major version would that solve your concern?

The earliest time we can do this is the next major release because of backwards compatibility.

@freak4pc That makes sense. I am mostly concerned about where things are located (RxCocoa), and not the why. @kzaher yeah, that would work. My hopes are mostly to separate the Variable alternative (BehaviorRelay) from any UI grouping. RxCocoa seems to be mostly geared toward working with UI pieces. Thank you both @freak4pc & @kzaher.

Hi all, please help me the right way to append value for BehaviorRelay . Is the solution of @sandeeplearner correct? I expected another way, because it seem verbose.