ValidationMessageStore.Add field accessor parameter shows a warning for nullable properties

[vuorinem]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Adding validation errors using the below ValidationMessageStore.Add method triggers a warning when nullable annotations are enabled for the project, and the property referenced in the accessor parameter has a nullable type.

aspnetcore/src/Components/Forms/src/ValidationMessageStore.cs

Lines 38 to 39 in 2f68ef8

	public void Add(Expression<Func<object>> accessor, string message)
	=> Add(FieldIdentifier.Create(accessor), message);

Expected Behavior

No warnings are displayed for properties with nullable type.

Steps To Reproduce

The following code shows how the warning message is triggered:

private TestModel model = new();

private class TestModel
{
    public string? Text { get; set; }
}

private void ManualValidation()
{
    var messageStore = new ValidationMessageStore(editContext);

    if (true /* External validation rule */)
    {
        messageStore?.Add(() => model.Text, "This value is not valid");
        //                      ^^^^^^^^^^  <-- Warning triggered here
    }
}

Full repro at https://github.com/vuorinem/aspnet_blazor_validationmessagestore_warning_repro/blob/6ba9b0a2b4fe0f38c1da6e7e5577dd75083dc9b6/BlazorApp1/Pages/Index.razor

Exceptions (if any)

No response

.NET Version

6.0.202

Anything else?

Changing the method signature to the following (from object to generic parameter TField) could fix the issue as far as I understand:

public void Add<TField>(Expression<Func<TField>> accessor, string message)

That would match the the method in FieldIdentifier:

aspnetcore/src/Components/Forms/src/FieldIdentifier.cs

Line 20 in 2f68ef8

public static FieldIdentifier Create<TField>(Expression<Func<TField>> accessor)

Thanks for contacting us.
We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.