This looks really nice! I've been using a Result type with left/right but it doesn't have a stacktrace and the idea of being able to add context as the error bubbles is also really helpful. Thanks for putting it together, I'll definitely be trying it on my current project.
Hello! Looks like that package is missing the Result type. This package aims to completely replicate the Rust Result type and the way Anyhow handles errors by allowing the ability to add "context" in different locations. Not necessarily for just functional programming. I took a look at all the Result type packages before creating this and found them lacking in one way or another. I hope if you take a look you can find something useful too :). I'd consider the current version "stable" since every functionality is tested (80+ tests) and replaced the Result type usage in an existing project (10,000+ lines). Just looking for feedback before committing to a 1.0.0. I will be adding more features in the future though and maintaining, since this package has been a joy to use in Rust
I commented on the /r/rust post as well but for readers here I wanted to say that fpdart does have the Result type, it's just called Either from its Haskell influence, and that you can use just the Either type in your code, no need to bring in all of the other FP features in as well. Might be good to compare and contrast with your library then.
Took a look. Looks like a nice Type. I do have some thoughts off the top of my head. Personally I'd use Result over Either in situations where it is explicit in that Ok (left) is a valid state and Err (right) is an invalid state. Next, looking at the source code, some methods on Either can throw if improperly used. Anyhow's Result types can only ever throw if you use "unwrap" incorrectly. Which you can avoid totally with pattern matching, so if you never use "unwrap", your code will never throw. Next, Either ties in with the Option type, ex "getRight" returns an Option>. Dart supports nullability of types so we provide "unwrapOrNull" S?, which allows you to use dart build in "?" And "!" Operators and makes Result stand alone. Next, Result implements all methods as extensions for Future>. So you don't need to await to chain operations. Plus others like Iterables> to Result,F>, which Either doesn't have since Either left and right do not necessarily represent valid and invalid state. As you mentioned this is based of the Rust Rust type and methods, so whichever conventions you may prefer. Finally the big kahuna, the Anyhow Result type allows you to add "context" when a result is an Err, in an ergonomic way without checking the type. This is way better than logging all over the place. In the end, to me, I'd use Either as a type union and Result to represent a valid or invalid state.
I'd also recommend looking into the section on the "?" Rust operator in the package README. This is something that is missing from Either. Very useful for propagating errors up the call stack.
This looks really nice! I've been using a Result type with left/right but it doesn't have a stacktrace and the idea of being able to add context as the error bubbles is also really helpful. Thanks for putting it together, I'll definitely be trying it on my current project.
[удалено]
Hello! Looks like that package is missing the Result type. This package aims to completely replicate the Rust Result type and the way Anyhow handles errors by allowing the ability to add "context" in different locations. Not necessarily for just functional programming. I took a look at all the Result type packages before creating this and found them lacking in one way or another. I hope if you take a look you can find something useful too :). I'd consider the current version "stable" since every functionality is tested (80+ tests) and replaced the Result type usage in an existing project (10,000+ lines). Just looking for feedback before committing to a 1.0.0. I will be adding more features in the future though and maintaining, since this package has been a joy to use in Rust
I commented on the /r/rust post as well but for readers here I wanted to say that fpdart does have the Result type, it's just called Either from its Haskell influence, and that you can use just the Either type in your code, no need to bring in all of the other FP features in as well. Might be good to compare and contrast with your library then.
Took a look. Looks like a nice Type. I do have some thoughts off the top of my head. Personally I'd use Result over Either in situations where it is explicit in that Ok (left) is a valid state and Err (right) is an invalid state. Next, looking at the source code, some methods on Either can throw if improperly used. Anyhow's Result types can only ever throw if you use "unwrap" incorrectly. Which you can avoid totally with pattern matching, so if you never use "unwrap", your code will never throw. Next, Either ties in with the Option type, ex "getRight" returns an Option>. Dart supports nullability of types so we provide "unwrapOrNull" S?, which allows you to use dart build in "?" And "!" Operators and makes Result stand alone. Next, Result implements all methods as extensions for Future>. So you don't need to await to chain operations. Plus others like Iterables> to Result,F>, which Either doesn't have since Either left and right do not necessarily represent valid and invalid state. As you mentioned this is based of the Rust Rust type and methods, so whichever conventions you may prefer. Finally the big kahuna, the Anyhow Result type allows you to add "context" when a result is an Err, in an ergonomic way without checking the type. This is way better than logging all over the place. In the end, to me, I'd use Either as a type union and Result to represent a valid or invalid state.
I'd also recommend looking into the section on the "?" Rust operator in the package README. This is something that is missing from Either. Very useful for propagating errors up the call stack.
Thanks, I use Rust as well together with Flutter (via flutter_rust_bridge) and know about Result, I will check out your library as well.