[Feature request]: Add a signal to PropertyType

[NachoSoto]

I think this was debated at some point but I can't find any other issue.

It would be nice if PropertyType also exposed a Signal<Value, NoError>. Of course we can do property.producer.skip(1), but it would be nice to have its own method to expose this with the right no-side-effects semantics.

[neilpa]

I would take this a step further to say that PropertyType should conform to both SignalType and SignalProducerType.

[NachoSoto]

Yes, absolutely! But that's going to require higher-kinded types so that things like SignalType.map can return Self<Value, Error>.

[neilpa]

Nope, SignalType exposes signal: Signal<Value, Error> and doesn't use Self because of that.

[NachoSoto]

I would take this a step further to say that PropertyType should conform to both SignalType and SignalProducerType.

What I mean is that operators, like map, are implemented on SignalType, but they can't return Self<Value, Error>, they incorrectly return Signal.

If PropertyType were to conform to SignalType, for example, doing property.map would return a Signal, which is wrong. It should return another property of the same type.

That's why I'm saying that unfortunately what you suggest is not possible right now.

[neilpa]

they incorrectly return Signal.

I wouldn't call this incorrect given that this is a language limitation and there's nothing we can do to workaround it.

[NachoSoto]

For sure, hence the italic :)

[paulyoung]

It was originally brought up in #2146. I wish I had this all the time but never got around to it.

[NachoSoto]

@neilpa do you have any further thoughts on this?

Given that, as I explained, we can't make it conform to SignalType yet, seems like an appropriate temporary solution to simply add a Signal.

This isn't blocking 4.0 though, of course.

[neilpa]

Nope, we should just go ahead and add it.