Fixed the unbound memory growth of unidirectional bindings.

[andersio]

	if let disposable = disposable {
		target.lifetime.ended.observeCompleted { disposable.dispose() }
	}

would leave the disposable of a disposed binding in the lifetime signal forever (until the lifetime ends).

I also notice one thing — observe would show up in the code completion of Property and SignalProducer, but neither use this term. Perhaps it would be better to rename it to bind(_:during:).

[andersio]

This doesn't seem the only leak though...

[liscio]

Changes look good, but I agree that the naming is unfortunate. I initially wondered why observe had to be changed everywhere and then realized my misunderstanding.

With that said, what are your thoughts on addObserver(_:during:)?

[andersio]

Based on the API guidelines, it should be add(_:during:) though.

[andersio]

It seems there are some edgy cases in the binding model that haven't been caught. Our primitives themselves aren't leaking.

[mdiep]

Can we add a test for this?

[mdiep]

I actually like the name as-is. The reality is that a Property or SignalProducer can be observed.

[andersio]

I actually like the name as-is. The reality is that a Property or SignalProducer can be observed.

SignalProducer cannot be observed. It produces a Signal that can be observed, aka start. It fits Property, but then observe and start have a different semantic in Property where the binding is using start.

Can we add a test for this?

Probably not. There is no public or internal API to catch the number of observers.

[mdiep]

SignalProducer cannot be observed. It produces a Signal that can be observed, aka start.

Even if it can't be observed directly, it can be observed. At any rate, this method is clearly side-effecting, so it deserves a direct verb name. Something like add won't do it justice.

Can we add a test for this?

Probably not. There is no public or internal API to catch the number of observers.

If it's disposable that's getting leaked, we should be able to do a standard weak test where we verify that it gets cleared at the appropriate time?

[andersio]

If it's disposable that's getting leaked, we should be able to do a standard weak test where we verify that it gets cleared at the appropriate time?

True without this fix, where the Lifetime observation shares the same disposable that is returned. But this fix internalised it with take(during:).

We may setup some burning tests that compares memory before and after the burning though.

[andersio]

Even if it can't be observed directly, it can be observed. At any rate, this method is clearly side-effecting, so it deserves a direct verb name. Something like add won't do it justice.

I am not disagreeing with that. Just that observe has an established meaning that does not belong to at least the domain of SignalProducer — we have start as the MVP there. Now imagine an entry in code completion shows up with observe...