-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
promoteError
type inference.
#413
Conversation
Sources/Signal.swift
Outdated
@@ -2405,7 +2405,7 @@ extension Signal where Error == NoError { | |||
/// - _ An `ErrorType`. | |||
/// | |||
/// - returns: A signal that has an instantiatable `ErrorType`. | |||
public func promoteErrors<F: Swift.Error>(_: F.Type) -> Signal<Value, F> { | |||
public func promoteError<F: Swift.Error>(_: F.Type = F.self) -> Signal<Value, F> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome
/// - _ An `ErrorType`. | ||
/// | ||
/// - returns: A signal that has an instantiatable `ErrorType`. | ||
public func promoteError(_: Error.Type = Error.self) -> Signal<Value, Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait why is this overload necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It isn't necessary, just that it allows one adds promoteError
to everything in a brute force manner, while not yielding extra Signal
s in cases with the identical error types. Say if you do:
SignalProducer<Int, CocoaError>.combineLatest(
SignalProducer<Int, CocoaError>.empty.promoteError(),
SignalProducer<Int, NoError>.empty.promoteError()
)
The resulting Signal
graph would be equivalent to:
SignalProducer<Int, CocoaError>.combineLatest(
SignalProducer<Int, CocoaError>.empty,
SignalProducer<Int, NoError>.empty.promoteError()
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very much 👎 for that. Since when has RAC promoted brainless thinking? :P A user calling this operator when they shouldn't is likely an error and shouldn't be silenced IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps I should be more careful about my wordings. The overload does not add any capability, and is just a fast path when the compiler knows Self.Error
is the Error
of the return producer.
Say SignalProducer<Int, CocoaError>.empty.promoteError(CocoaError.self)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oooh that's right, because it's not possible to do negative conditions on extensions. This is a great idea then 👍
/// | ||
/// - returns: A producer that has an instantiatable `ErrorType`. | ||
public func promoteError(_: Error.Type = Error.self) -> SignalProducer<Value, Error> { | ||
return self |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto
Can you add a test to cover this automatic inference? |
Preceded by #408.
This is useful when combining multiple signals with
NoError
in the mix, reducing the verbosity.