We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
So, if Result(T) is interface, why not just create two
Result(T)
type ok(type T) T // Implement Result(T) type err(type T) error // Implement Result(T)
types implementing Result(T)?
type ok(T), err(T)
Ok
T
Err
error
The text was updated successfully, but these errors were encountered:
That's an interesting idea, but it feels like I don't really get your idea, what can we achieve by having these two types implementing Result(T)?
it would be great to achieve pattern matching at some point.
I think we could have a method that returns either Ok(T) or Err(T), so we would be able to use it in type-switch:
switch v := result.SomeMethod().(type) { case Ok(int): // case Err(int): /// }
But it still doesn't look really useful.
The Match() function already addresses this problem, but it requires passing two functions though.
Match()
Sorry, something went wrong.
Result(VeryBigStruct)
err
func (o ok(T)) Or(res Result(T)) Result(T) { return o } func (e err(T)) Or(res Result(T)) Result(T) { return res }
instead of
func (result *result(T)) Or(res Result(T)) Result(T) { if result.ok { return result } else { return res } }
No branches or pull requests
So, if
Result(T)
is interface, why not just create twotypes implementing
Result(T)
?Result(T)
(you can addtype ok(T), err(T)
constraint to prohibit any other implementations)Ok
's size is equal toT
andErr
's size is equal toerror
The text was updated successfully, but these errors were encountered: