Add Property.filter

[iv-mexx]

Checklist

• Updated CHANGELOG.md.

A filter operator for Property has one edge case: Property always needs to have a value, but what if the predicate excludes the current (or all) values of the source Property?
Probably thats the reason that this operator was not yet included for Property?

I suggest to provide an initial value for the filtered Property to handle that case.

[andersio]

Back in the times when introducing property composition, I had considered having these lifted to output optionals, but apparently that would be nasty to consume.

I'd approve but we probably need more eyes on this, since it'd set a precedence for future property operators. cc @ReactiveCocoa/reactiveswift

[andersio]

[Nit] New property operator: filter. 😛

[iv-mexx]

👍

[andersio]

Remove .init.

[iv-mexx]

👍

[andersio]

As a side note though, we often deal with streams of things we do not own (a la non instantiatable). In those cases optionality is a must, and we could do it in two ways:

1. having operators to output Property<U?>.

   let resource: Property<UniqueResource>
   resource.filter { $0.hasExpired } // Property<UniqueResource?>

2. apply map to optionalise, and having these operators working on opaque Value with mandatory initial value. i.e. this PR.

   let resource: Property<UniqueResource>
   resource
       .map(Optional.init)
       .filter(initial: nil) { $0.hasExpired } // Property<UniqueResource?>

Going after (1) hampers simple use cases, when there is an obvious initial value, e.g. some sort of flag derived from the content.

Meanwhile, despite (2) hampering cases with mandatory optionality in favour of simple uses, it is also IMO more explicit.

[iv-mexx]

I had considered having these lifted to output optionals, but apparently that would be nasty to consume.

I had considered that as well at first, but it was indeed awkward to use.

[mdiep]

I'm curious why you found it awkward to use. Returning a Property<U?> seems like it might make more sense to me. You could always do property.filter(condition).map { $0 ?? initialValue }.

It does seem like either way would get painful if you were going to chain multiple things together:

property
    .filter(initial: 1, condition1)
    .filter(initial: 1, condition2)

It'd be nice if we had could do something to propagate that through with some sentinel value. But I don't think that possible with the current APIs. 🤔

[iv-mexx]

"Awkward" may be the wrong word for it.

Basically, it feels strange to me to introduce an optional, when "just" the initial value is missing, something that I have to deal with regardless of the filter operator already:

I often have (Mutable) properties that will always have a value, but a first "valid" value is not available at initialization. Since the value will not change back to nil, using an optional fells wrong and is often tedious down the line, so I have to find a suitable initial value anyway, e.g. empty string, empty array, ...
Now using a filter operator on such a property feels pretty similar. Sure, there are now more cases where a value might not be passed on so the property might keep the initial value longer / for ever, but once a value passes through, it does not change back to nil anymore. And since I had to choose a suitable (non-optional) initial value for the initial property, I can use the same initial value for the filter operator.

It'd be nice if we had could do something to propagate that through with some sentinel value.

This would be really great in my described use case but goes way over my head implementation wise 😆

You could always do property.filter(condition).map { $0 ?? initialValue }.

Yeah,i f you think filter outputting an optional is the correct to go than I have no problem with doing that. In the case @andersio mentioned that might be the better option anyway...

[mdiep]

I think I'm on board with passing in the initial value like you have here. I don't see a truly better option.

[jjoelson]

Another (possibly stupid) idea would be to have the new property always start with the current value of the existing property and then filter all subsequent values. I think this would make the operator pretty seamless to use in most cases, though it might make it too easy to make a mistake.

[mdiep]

Thanks @iv-mexx!