Nullable reference types support

[adambajguz]

.NET slowly transisions to code that uses nullable reference types. It would be great if Validot supports nullable reference types.

Problem:

public record Model
{
	public string? Language { get; init; }
}

public sealed class ModelValidator : ISpecificationHolder<Model>
{
	public Specification<Model> Specification { get; }

	public ModelValidator()
	{
		Specification = m => m
			.Member(x => x.Language!, language => language // must use a null forgiving operator to use the IsLanguageCode extension 
				.IsLanguageCode()
			);
	}
}

public static IRuleOut<string> IsLanguageCode(this IRuleIn<string> @this) // string doesn't allow a null
{
	// some code
}

I can replace IRuleIn<string> with IRuleIn<string?> but "If the value entering the scope is null, scope commands are not executed." (DOCUMENTATION.md#null-policy) and using null forgiving operator is for me awful.

Nullable support in .NET Standard 2.0

Nullable package can be used to add nullable reference types to .NET Standard and/or a multi-target package can be created (I've never checked how e.g. .NET 6 handles nullable annotations from .NET Standard 2.0 package because I've always used multi-targeted packages so this need verification).

 <PropertyGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
    <Nullable>annotations</Nullable>
  </PropertyGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0' or '$(TargetFramework)' == 'netstandard2.1'">
    <PackageReference Include="Nullable" Version="1.3.0" PrivateAssets="all" />
  </ItemGroup>

[bartoszlenar]

Hi @adambajguz , thank you for pointing this out.

Yes, I've been thinking about it intensively for a year now. Recently, after releasing 2.3, I made a decision and because thanks to you there is an issue about nullable reference types, I feel obliged to share my plans for Validot in that matter.

Two statements to start with:

• Nullable reference types are the future and Validot handles them poorly. I don't like reading code screaming at me.
• Validot depends on the framework and on the framework only. That's one of the principles I've taken and I'll continue to follow it. Also, I'm not an expert in multi-target packages, nor am I willing to become one.

What's the solution, then?

• At the end of 2022 Microsoft ends the support for the last .NET Core version (3.1). From this moment, all LTS versions will be the "new" .NET.
• Validot policy will be to target the framework version that is (at the moment of the release) the LTS with the longest time on the market (so, the oldest still supported LTS).

What's the plan?

I'll release two or three versions with as many features (for sure #5 and #26) as I can code within reasonable amount of time. So let's say there will be 2.5, 2.6 and 2.7 still targeting .NET Standard 2.0. This way I'll ensure that features achievable now are available for the broader audience with legacy projects.

Only then I'll redirect my efforts to making version 3.0, which will include native support for nullable reference types on top of other minor breaking changes.

[adambajguz]

Sounds like a reasonable plan! Thanks for sharing it!