-
-
Notifications
You must be signed in to change notification settings - Fork 87
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 Fold function to Result monad #42
Conversation
I would use the same prototype as other methods: Feel free to add this method to the other types. Or I will do it by myself. |
@samber Okay I think you are asking to have something like that func (r Result[T]) Fold(successFunc func(T) T, failureFunc func(error) T) T {
if r.err != nil {
return failureFunc(r.err)
}
return successFunc(r.value)
} However, I was thinking that the Fold function could map the result to a new type. This would allow the client (AKA the caller) to use custom functions that return any value based on their specific logic needs. For example, if the result monad encounters an error, instead of returning a fallback integer value, I would like to return a string containing an error message. So what do you think about that |
To date, Go does not allow type parameters on methods: golang/go#49085 . I don't really like returning interfaces, since it is not very typesafe. In your case, I would suggest an additional helper: IMO type foldable interface[T, U] {
left() T
right() U
} |
@samber Here are the changes. Are you okay with these changes before implementing the Foldable interface in the remaining types (Either & Option)? Also, I have a question: I've noticed different implementations of the fold function in various languages/packages. For instance, for the Result<TValue, TError> monad, the fold function always returns a value of type TValue, as you mentioned here. However, in other packages, I see that the fold function returns a new type. So, I'm unsure which approach makes more sense. Should we make the fold function consistently return the same type |
Looks good. I think we can return a different type in the case of |
@@ -15,6 +15,6 @@ jobs: | |||
stable: false | |||
- uses: actions/checkout@v2 | |||
- name: golangci-lint | |||
uses: golangci/golangci-lint-action@v3 | |||
uses: golangci/golangci-lint-action@v5 |
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.
Update to newer version as I got the following linting error
func Result[T].{{func_name}} is unused (unused)
regarding those functions
@samber I have changed method names for Foldable interface to make sure method names will not conflict with field names in the Either struct. Are you okay with that 👀 |
Looks good! Let's merge ;) |
This pull request introduces
Fold
function to theResult
monad, enhancing its functionality and making it more versatile for handling both success and failure scenarios.Changes Made:
Fold
function within theResult
monad, allowing for streamlined handling of success and failure cases.Fold
function takes two callback functions as arguments:successFunc
: A function to be applied if theResult
contains a successful value. It transforms the value into another type.failureFunc
: A function to be applied if theResult
contains an error. It transforms the error into another type.Result
contains an error, theFold
function applies thefailureFunc
to the error and returns the transformed result.Result
contains a successful value, theFold
function applies thesuccessFunc
to the value and returns the transformed result.Benefits:
Result
monad.Result
monad by enabling developers to easily define custom behavior for different scenarios.Result
monad itself.Example: