extend Result<T> with an implicit operator Result<T>(in Exception error) ?

[wgross]

I'm exploring currently the concept of Result datatype in context of bindings to a low-level C-API. I've implemented a simple result type for this as a ref struct and I'm looking now into adopting the dotnext result type instead.

What I 've added to my implemention was a conversion operator from Exception:

[Pure]
public static implicit operator Result<T>(in Exception reason) => Result.Error<T>(reason);

This allows me to alternatively return a T or an Exception:

Result<int> Function()
{
    // good case
    return 10;
    
    // bad case
    return new Exception("fail");
}

For me this feels pretty sweet because I don't have to explicitly put the T in the error generation: Result.FromException<int>(new Exception("fail"))

Has something like this been discussed and thrown out?
Any opinions on that?

[sakno]

Thanks for your proposal. Let's start from signature:

public static implicit operator Result<T>(in Exception reason)

No need to use in modifier because Exception is by-reference type already. Currently, Result data type doesn't provide implicit operator for exceptions because of ambiguity:

public static implicit operator Result<T>(T result);
public static implicit operator Result<T>(Exception reason);

Which one should be used if T is Exception or any other derived exception?

[sakno]

I don't have to explicitly put the T in the error generation

With target-typed new expression it's not needed, just return new(new Exception("fail")).

[wgross]

I understand the ambiguity argument..
BUT I believe ambiguity is already there.. or I totally missed the point:

Just hacked some quick test cases in my linpad: For a Result<T> where T is Exception new(new Exception()) doesn' t generate a result which is IsSuccessful. Ambiguity must be resolved by using the factory methods today already.

[Fact] 
void Test_result_is_exception_ctor_ambiguity()
{
	Result<Exception> Function()
	{
		return new(new Exception());
	}

	// result isn't a success, but was meant to be..
	Assert.False(Function().IsSuccessful);
	Assert.Throws<Exception>(() =>Function().Value);
}

[Fact]
void Test_result_is_exception()
{
	Result<Exception> Function()
	{
		return Result.FromValue(new Exception());
	}
	// succeeds
	Assert.True(Function().IsSuccessful);
}


[Fact]
void Test_result_is_exception_but_has_error()
{
	Result<Exception> Function()
	{
		return Result.FromException<Exception>(new Exception());
	}
	// succeeds
	Assert.False(Function().IsSuccessful);
}

[sakno]

Roslyn prevents compilation of the following code:

static Result<Exception> GetResult() => new Exception();

because of ambiguity. Let's assume that the developer must replace this code with explicit factory method. But what about the following code (that .NEXT has already):

Result<string>? r = TryGetResult<string>(task: null);
NotNull(r);

public static Result<TResult>? TryGetResult<TResult>(this Task<TResult>? task)
        => task is { IsCompleted: true } ? GetResult(task, CancellationToken.None) : null;

What would you expect from r? Surprisingly, but r is not null. Because null is treated by the compiler as (Exception)null, not as (Result<TResult>?)null. As a result, introduction of implicit operation breaks source-level backward compatibility at least in .NEXT itself. Definitely, it will break the dependent libraries as well. It's very hard to investigate the problem because the source code can be compiled without any changes.