Remove implicit Result -> Result<T>

[Tim-Hodge]

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:

using FluentResults;

bool fetchUserName = false;
bool useDefault = true;

var res = fetchUserName
    ? GetSomeUserName() // Result<string>
    : useDefault
        ? Result.Ok() // oops, forgot to set the default. Implicit cast to Result<string>(default)
        : new Error("No name found");

Console.WriteLine(res.IsSuccess ? $"Username is '{res.Value}'" : "Nothing");

Result<string> GetSomeUserName() => Result.Ok("user");

My expectation is that res should have some valid string value. In this instance Result.Ok() is implicitly cast to Result<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 losing T, the compiler would catch any expectations of T.

[altmann]

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.

[anthonylevine]

Would love to see this pulled out as well. Thanks again for the great library!!!