New nullability annotation to capture GetType(..., throwOnError: true) semantics

[jnm2]

When you call Assembly.GetType("Foo", throwOnError: true), there is a guarantee that it will either throw (not return) or return a non-null value.

It would be nice for throwOnError: true to not require ! whenever it is used, but the current nullability attributes don't provide a way of saying, "Not null if the named parameter is true."

Does something along these lines have merit?

[return: NotNullWhenEqual(nameof(throwOnError), true)]
public virtual Type? GetType(string name, bool throwOnError) => ...

namespace System.Diagnostics.CodeAnalysis
{
    [AttributeUsage(AttributeTargets.Field | AttributeTargets.Parameter
        | AttributeTargets.Property | AttributeTargets.ReturnValue, Inherited = false)]
    public sealed class NotNullAttribute : Attribute
    {
        public NotNullAttribute();
    }
    
    [AttributeUsage(AttributeTargets.Parameter, Inherited = false)]
    public sealed class NotNullWhenAttribute : Attribute
    {
        public NotNullWhenAttribute(bool returnValue);

        public bool ReturnValue { get; }
    }

+   [AttributeUsage(AttributeTargets.Field | AttributeTargets.Parameter
+       | AttributeTargets.Property | AttributeTargets.ReturnValue, Inherited = false)]
+   public sealed class NotNullWhenEqualAttribute : Attribute
+   {
+       public NotNullWhenEqualAttribute(string parameterName, object parameterValue);
+
+       public string ParameterName { get; }
+       
+       public object ParameterValue { get; }
+   }
}

[danmoseley]

@jaredpar should this go in the dotnet/csharplang repo?

[stephentoub]

FWIW, we discussed exactly such an attribute for exactly this (and other similar) cases in corelib when designing the initial set of attributes, and it was deemed too niche / too limited of an impact to be worth the extra complexity / cost.

[HaloFour]

Perhaps new methods, like Assembly.GetTypeOrThrow() would be a better addition to the BCL.

[theunrepentantgeek]

When you call Assembly.GetType("Foo", throwOnError: true), there is a guarantee that it will either throw (not return) or return a non-null value.

Arguably, the problem here is the API design choice to use throwOnError as a parameter instead of providing two distinct methods.

FWIW, a team I once worked on (developing in Delphi) used the convention that GetType() would throw if not found, but FindType() might return nil.