[API Proposal]: Provide trim-safe overload for ValidationContext construction

[captainsafia]

Background and motivation

The only trim-unsafe codepaths in the ValidationContext currently are invoked when no explicit Display is set on a ValidationContext. In this case, the ValidationContext will use unbounded reflection to discover the Display attribute on a type to support resolving it.

This presents a challenge to components that always initialize the DisplayName property as they always have to mark the construction of the ValidationContext as trim-safe even when it is not.

API Proposal

namespace System.ComponentModel.DataAnnotations;

public sealed class ValidationContext
{
    public ValidationContext(object instance, string displayName, IServiceProvider? serviceProvider = null, IDictionary<object, object?>? items = null)
}

API Usage

// Trim-safe initializtion of ValidationContext
var validationContext = new ValidationContext(42, "MyMagicNumber", null, null);

Alternative Designs

The proposed API only adds the displayName parameter to the most-specific constructor on the ValidationContext type. We can consider adding constructors with the other permutations of this type.

Risks

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-componentmodel-dataannotations
See info in area-owners.md if you want to be subscribed.

[tarekgh]

Would be better to default the serviceProvider and items to nulls?

[captainsafia]

Would be better to default the serviceProvider and items to nulls?

We can. I over-indexed on the existing constructor overloads for this but we can use a default value in these new overloads. I'll edit the proposal.