Remove Property source capturing.

[andersio]

The PR proposes to have composed properties not retaining its sources. This test case helps illustrate the new behaviour.

Recall that retaining Property would defer the termination of the event stream. Source capturing retains the sources, causing the sources' lifetime being a union with the lifetime of all their derivatives.

However, if we consider properties are just streams of values with a stronger guarantee than Signals (having one latest value), operators - that are fundamentally an observation - should not have a side effect on the observed event stream. In this sense, source capturing should be dropped.

It also adds a new initializer Property(reflecting:), which does the same thing as Property(_:) but without retaining the supplied property.

The default initializer Property(_:) is changed not to capture the supplied property, while the capturing "existential" variant is renamed to Property(capturing:). The renaming makes a better migration path when we deprecate the initializer as generalised existential lands in Swift.

P.S. Existential properties serves to work around the current language limits, so they should be left untouched.

Background

As brought up in #58 (comment), I have made a review on why we had composed properties capturing its source.

It was originated in ReactiveCocoa/ReactiveCocoa#2788:

Chain constructs like let p1 = p0.map { $0.location }.map { $0.latitude } are not safe with the proposed implementation, unless you explicitly capture p0 for the whole p1's lifecycle.

It was true at that time, since the property composition operators wasn't a thing yet, and the composition is done through AnyProperty which at that time was based on MutableProperty. So had we not made the property captured, chaining of map would not behave as expected.

But now with the property composition formally introduced, we propagate the values using replayed producer, which works properly when chained, rendering the need of capturing moot.

[NachoSoto]

Sounds reasonable

[sharplet]

Just wanted to note that reflecting doesn't feel quite right to me, though I haven't been able to come up with a suitable alternative yet.

[sharplet]

Ok, so the main use I have for the existential initialiser is this pattern:

private let _foo: MutableProperty<Foo> var foo: Property<Foo> { return Property(_foo) }

I kind of feel like this initialiser should not retain the underlying property by default. Then, to opt into capturing semantics, you could have:

return Property(capturing: _foo)

What do you think?

[andersio]

@sharplet Yeah, it does seem better. It would be a better default when generalised existentials eventually land in Swift, and we have the existential initializer deprecated.

[sharplet]

This looks good to me.

[andersio]

Should we mark AnyProperty(_:) renamed to Property(capturing:) instead? Or mark it as deprecated and tell the user there are two variants (no auto-fixit) instead?

@ReactiveCocoa/reactiveswift

[sharplet]

I've seen some fixits that provide multiple alternatives (unfortunately can't recall which, specifically) — maybe that's worth exploring?

[andersio]

Hmm... the unavailable annotation of AnyProperty the type has a higher precedence than Property any of its methods... So annotating init does not translate into anything.

[andersio]

We probably can't do any better. So perhaps we should just let it be. 🙈