-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add: Fallible.init(_:error:using:) #128
Comments
oscbyspro
added
addition
oh, so shiny!
brrr
such code, much wow
maybe
to do, or not to do?
labels
Nov 12, 2024
Having thought about this for some time, I'm leaning in the other direction. I'm not convinced that this is a problem that needs solving. Similarly, the static |
oscbyspro
added
no
don't even think about it
and removed
maybe
to do, or not to do?
labels
Nov 29, 2024
oscbyspro
added
maybe
to do, or not to do?
and removed
no
don't even think about it
labels
Nov 29, 2024
I'm working on a mini extension Fallible {
@inlinable public init<Error>(
_ value: consuming Value,
error: consuming Bool = false,
using setup: (inout Value, inout Bool) throws(Error) -> Void
) throws(Error)
} |
oscbyspro
changed the title
Add: Fallible.sink(_:performing:)
Add: Fallible.init(_:error:using:)
Nov 30, 2024
oscbyspro
added
maybe
to do, or not to do?
and removed
maybe
to do, or not to do?
labels
Nov 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I stumbled upon this ceremony while working on composable (#126) algorithms:
It isn't terrible, but a
Fallible.sink(_:performing:)
is perhaps more ergonomic:The text was updated successfully, but these errors were encountered: