MemberNotNullWhenAttribute completely ignored for async methods

[SoftCircuits]

I have code similar to the following.

public List<string>? Data { get; set; }

[MemberNotNullWhen(true, nameof(Data))]
public bool Read()
{
    Data = ReadData();
    return Data != null;
}

This works great. But now I want to add an async version of this method.

[MemberNotNullWhen(true, nameof(Data))]
public async bool ReadAsync()
{
    Data = await ReadDataAsync();
    return Data != null;
}

This compiles just fine and gives no warnings. But the MemberNotNullWhenAttribute is completely ignored. Using Data after this method returns true still gives the warning that it could be null.

This is for a NuGet package so eliminating that warning is pretty important. Is there no way to support this? Is there a workaround? Is a change needed to this attribute? Is a new attribute needed? I would settle for MemberNotNullAttribute working here.

At the very least, I think the compiler should issue some warning that the MemberNotNullWhenAttribute is going to be ignored.

[spydacarnage]

I assume this is because the method doesn't ever return true.
It returns a Task<bool>, which might contain a bool, it isn't one, and thus can never be true...

I imagine you could write an analyser yourself that detects whether you are using that attribute on a method that can't return true?

[SoftCircuits]

@spydacarnage Not sure what you mean by writing an analyzer myself. How could that be used by consumers of my library so that nullable reference warning would be appropriate?

[spydacarnage]

The analyser would be to provide you the warning that you'd used the attribute in an incorrect location. It wouldn't directly help your users or ultimately fix your NRT warning issue.

[333fred]

Duplicate of #5657.

[jnm2]

What if this attribute retroactively started having a real meaning on async methods, rather than introducing a second attribute as in #5657?

[SoftCircuits]

@jnm2 That seems the most straight forward to me.

However, the actual return type in my example is Task<bool>, so technically the actual return value could never be true. So I'd be okay if a new attribute was used to handle this particular case.

[jnm2]

It's the fact that the attribute is currently never meaningful on a (serious) awaitable method that seems to leave the space open to allow one attribute to have both meanings. The non-When case, though, does make me think there should be two attributes.

[SoftCircuits]

It should be pointed out that Intellisense thinks the MemberNotNullWhenAttribute attribute works. For example, if I do the following:

[MemberNotNullWhen(true, nameof(Data))]
public async bool ReadAsync()
{
    Data = await ReadDataAsync();
    return true;
}

I will get a warning:

Warning CS8775 Member 'Data' must have a non-null value when exiting with 'true'.

So it appears that the fact this attribute has no effect with async methods is something that just hasn't been looked at or considered.

Unfortunately, I see no good workaround for this issue.