Nullability enforcements when working with Deconstruct

[AlbertoMonteiro]

In NET 5 we have many attributes that help the compiler to know when a field may be null or not.

But it lacks support when you use Deconstruct.

I have the given type

public struct Result
{
    public Exception? Exception { get; }

    [MemberNotNullWhen(false, nameof(Exception))]
    public bool IsSuccess { get; }

    public Result(bool success)
    {
        IsSuccess = success;
        Exception = null;
    }

    public Result(Exception exception)
    {
        Exception = exception;
        IsSuccess = false;
    }

    public bool ErrorIs<TException>()
        where TException : Exception
        => Exception is TException;

    public static Result Success()
        => new(true);

    public static Result Error(Exception exception)
        => new(exception);

    public static Result<T> Success<T>(T value)
        => new(value);

    public static Result<T> Error<T>(Exception exception)
        => new(exception);

    public static implicit operator Result(Exception exception)
        => new(exception);

    public static implicit operator bool(Result result)
        => result.IsSuccess;

    public static implicit operator Task<Result>(Result result)
        => result.AsTask;

    public void Deconstruct(out bool success, out Exception? exception)
        => (success, exception) = (IsSuccess, Exception);

    public Task<Result> AsTask => Task.FromResult(this);
}

When I use it, the compiler gives me the proper warning if I do this:

No warning, since IsSuccess is false

But this Result type supports Deconstruct, and when I use it, I don't have the same benefit of this previous version

Also, I cant use the NotNullWhen, since the method does not return

public void Deconstruct(out bool success, [NotNullWhen(false)] out Exception? exception)
    => (success, exception) = (IsSuccess, Exception);

Is there a way to do it, and if not, are there any plans to support that kind of feature?

[RikkiGibson]

I think it's reasonable that people want this, but that if we chose to support it, that it might end up being part of a general "associate flow state with bool locals" feature. e.g.

object? x = ...;
bool isNull = x == null;
if (!isNull) x.ToString(); // ok

since it seems to exhibit the same problems of:

1. how do you store conditional state associated with a bool local "on the side" that gets integrated in when the bool is tested
2. how do you invalidate that state appropriately when effects occur in-between the assignment and usage of the local e.g.

(Success, Exception) = Result.Success();
Exception = null; // should invalidate conditional state associated with 'Success'
if (!Success) Exception.ToString(); // should warn

[333fred]

We would need a general alias analysis to perform this, which we have previously said is not worth the tradeoffs in performance.

[AlbertoMonteiro]

@RikkiGibson this already happens today.

As you can see there is no warning about the exception being null.

Because I annotated like that

And if I change the if statement, then it warns.

So, if we had the possibilitity to do that in deconstructing way, we would be in same "place" as using MemberNotNullWhen, it would be partially covered.
Better than nothing.

[333fred]

This is one of those cases described in https://xkcd.com/1425: it sounds easy, but is actually quite hard. Properties are a single location where the access occurs and the check occurs at the same location. Doing the same thing where one local location affects another local location is significantly more complex and, while possible, has generally not met the team's cost/benefit ratio for both the implementation difficulty and the cost to runtime performance.

[AlbertoMonteiro]

Gotcha @333fred ,thanks for clarification