Move Signal and SignalProducer operators to the concrete types. #304
+171
−166
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SignalProducer
heavily intertwines withSignal
at its core, while bothSignalProducer
andSignal
are already pretty generic with refinements & specialisation enabled through closures & type erasure, IMO mitigating the need of another hot signal type. Moreover,Property
is not going to conform to either of them due to clashes in base names, even assuming the presence of higher-kinded types in Swift.So with all these, I do not envision any value of semantic abstraction from these protocols.
The PR does not remove
SignalProtocol
andSignalProducerProtocol
however, since they are still necessary for constraining flattening operators until we have parameterised extensions.