-
-
Notifications
You must be signed in to change notification settings - Fork 104
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
Remove implicit Result -> Result<T> #171
Comments
I totally agree. We added in the last year some implicit conversions with the advantage that you don't have to type that much code. The disadvantage is (as you know) the missing type safety. I'am also not a big fan of this implicit conversions and maybe I will remove it from the lib in the next major version. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unsure whether this is desirable behaviour, but I believe this implicit conversion can lead to bugs. I'm not sure where it provides value compared to the risk of misuse.
Consider the following contrived example:
My expectation is that
res
should have some validstring
value. In this instanceResult.Ok()
is implicitly cast toResult<string>(default)
, and hides the fact that a string value was not assigned.Whilst it might be obvious in this simple example, in more complex scenarios where
.Bind()
calls are chained it is much easier to miss. It feels like the compiler should catch such cases.I would have expected the opposite conversion to work;
Result<T> -> Result
. Whilst this has the effect of losingT
, the compiler would catch any expectations ofT
.The text was updated successfully, but these errors were encountered: