Is null-state static analysis half-done?

[deep-outcome]

I was grubbing among such said null-state static analysis, for instance Attributes for null-state static analysis and I can tell some acumens so far:

1. Why it is null-state analysis if it works with nullable value types which do not have null value but default value?

It is well known that for nullable value type null assignation is equal to assignation of default (default(Nullable<X>). (Drolly reference type has it just opposite.)

> int? i = null;
. Console.Write ("#1 "); Console.WriteLine (new Nullable<int> () == i);
. Console.Write ("#2 "); Console.WriteLine (new int? () == i);
. Console.Write ("#3 "); Console.WriteLine (default(int?) == i);
. Console.Write ("#4 "); Console.WriteLine (default(Nullable<int>) == i);
. Console.Write ("#5 "); Console.WriteLine (default == i);
#1 True
#2 True
#3 True
#4 True
#5 True

2. Practically the same goes for null-state static analysis attributes. Why they use null keyword when in .NET environment is preferable to use default whenever possible. This goes even for case if attributes worked just with reference type (and they do not).
3. What can it fix when compiler generates just warnings by default? It is expected that development leader will switch the rules to errors for whole team?
4. It has imperfect documentation with some not pretty mistakes like claim that nullable-annotation of reference type is part of method signature.
5. It has strong tendency to present that nullable value types magically can have null value.

Value type is never null. Even when it is declared as nullable via ? suffix, it is just shorthand for generic constructed closed value type, Nullable<X>, where X is corresponding value type. Thus to state out that null is fine value for instance of Nullable<int> variable is not true at all.

6. Some cases enforce annotation contract just fine. For instance

static void NotNull_RefNullableAnnotated ( [NotNull] ref string? s )
{
} // Warning CS8777 Parameter 's' must have a non-null value when exiting..

7. While the same exhibits senseless warnings

static void NotNull_NullableAnnotated ( [NotNull] string? s )
{
} // Warning CS8777 Parameter 's' must have a non-null value when exiting.

8. Generally previous sample denotes ability to use contract attribute for variables that do not participate in it, i.e. they are not by ref.

static bool MaybeNullWhen__NullableAnnotated ( [MaybeNullWhen (true)] string s )
// No problem that s does not point to argument.
{
  if ( DateTime.Now.Ticks % 3 == 0 )
  {
    s = null;
    return true;
  }

  s = null; // No problem with null.
  return false;
}

9. Some are broken

[return: NotNullIfNotNull ("a")]
[return: NotNullIfNotNull ("b")]
static string? NotNullIfNotNull ( string? a, string? b )
{
  if ( a is not null || b is not null )
    return null; // No problem here.
  
  return null;
}

…

[CyrusNajmabadi]

Why it is null-state analysis if it works with nullable value types which do not have null value but default value?

I'm not sure what this means tbh. Nullable value types definitely have a null value. That's the reason they're called 'nullable' :-)

[deep-outcome]

They definitely does not have null value.

They definitely do.

You are incorrect here.

Object o = null;
int? i = (int?)o;

They have a null value.

Likely I see what terminology is hidden among this. There is some realm pillar called null that in fact does not exists at all. It is abstract keyword that any kind of realm inhabitant explains by its nature. Thus:

• reference type is null when its memory space is all filled with zeros,
• value type is never null since at least it is default instead,
• Nullable<> struct can be null; its HasValue bool property is false. This happens in well-known cases.
• If there come any new inhabitant that will be about to tell anyone it cannot provide useful value information, independently of its nature it will be presentable as null then.

[deep-outcome]

but that is all. Nullable<> is struct thus it cannot be null

This is incorrect. Definitionally. You can try this trivially both in the language, or in the runtime. Just use reflection and you will both read and write actual null values from nullable-value-types. Seriously, go try it! :-)

I do it day by day. Just proper understanding was passing me aside. I saw it just as syntactic sugar (such said) but now I know it has also full semantic meaning.

[CyrusNajmabadi]

But this is keen fairy tail story.

There is no fairy tail here. The reflection examples demonstrate this. Again, I literally was part of the effort that did this work back in c#2. It's one of the first things I worked on in this group at ms after I moved over to devdiv :-)

[CyrusNajmabadi]

There is some realm pillar called null that in fact does not exists at all. It is abstract keyword that any kind of realm inhabitant explains by its nature

So I'm not sure how to evaluate this statement. null definitely exists and has a definition. Yes, you can say it has a description behind it... But that's true of everything in the language. There is a specification that states the semantics it should have and what is legal for it or not.

However, there is no different sort of 'null' in c# or .net. It's the same null at the language level and the runtime level. You can see that with my IL example. You can see the simplest opcodes for referring to null and then comparing against it. It's not something different. It's just null.

[deep-outcome]

It's just null.

Ok, ok. Everything nullable has its own null state, null equality, …

[CyrusNajmabadi]

Why they use null keyword when in .NET environment is preferable to use default whenever possible.

I know of no such preference in .net. The preference is to use 'default' for things that may not be null (for example value types, or unconstrained generics). Did things that can be null, 'null' is perfectly fine to use

[CyrusNajmabadi]

But not null.

You are incorrect. This is how it is literally defined in the language. and even if you don't care about the language, this is how the runtime works (which is trivial to verify).

[CyrusNajmabadi]

hmm, maybe it is some abandoned recommendation.

I don't think any such recommendation has ever existed. We have been firm and clear on what null is and how it relates to nullable value types since c# 2.

[333fred]

@333fred, hmm, maybe it is some abandoned recommendation.

Definitely not abandoned. This is very intentional on our part, and it's certainly my recommendation to any other user. null vs default gives important information: whether the value is some default for the domain (such as default(int)), or whether it's actually the absence of information, as null is.

[CyrusNajmabadi]

I can see someone using default for all use cases. It's consistent and simple. However, I'm with Fred that I prefer null for cases where null is the value. It's shorter, provides useful information, and is idiomatic.

[deep-outcome]

But not null.

You are incorrect. This is how it is literally defined in the language. and even if you don't care about the language, this is how the runtime works (which is trivial to verify).

I care about language. I mean I like it. But. Can you provide me with some reference?

I just went through ECMA-335 6th Edition / June 2012 finding just indirect clause.

Some methods traffic in “default values”. For a reference type, the default value is null; for a
nullable value type, the default value is HasValue returns false; for a non-nullable value type, the
default value is all-bits-zero (which for Boolean represents false, and for all arithmetic types
represents zero).

[CyrusNajmabadi]

Thus to state out that null is fine value for instance of Nullable variable is not true at all.

I genuinely cannot find where on the net this quoted statement comes from. However, I firmly disagree with it. null is absolutely fine for any nullable value type. That's literally the point of that feature. If there are docs or statements to effect that day otherwise, we should fix them.

[CyrusNajmabadi]

It cites me from another post.

Sorry, citing yourself isn't really an argument :). Your position does not match the language or runtime spec or implementation.

[HaloFour]

Nullable<T> isn't a normal struct. The runtime has special knowledge of it and will implicitly convert between it and a null reference. For example:

int? i = null;
object o = i;

Debug.Assert(o == null);

If this weren't the case o would be a boxed copy of a Nullable<T> struct that contained the sentinel value representing null. But that's not the case, o is an actual null reference.

[deep-outcome]

It cites me from another post.

Sorry, citing yourself isn't really an argument :). Your position does not match the language or runtime spec or implementation.

It was not about to present any meaning. That is obvious, of course.

[deep-outcome]

Am I wrong?

Yes. You are wrong. I say this as one of the people who worked on the design and impl of Nullable.

I see now. I was never aware that null and null reference are not interchangeable terms. Seeing that null is just “colloquial” form of latter one. Now it is everything clear. Null can be this and that.

[CyrusNajmabadi]

null is just null. It's valid for (and 100% interchangeable) between direct reference types, and nullable value types. That's literally why they're called 'nullable'. Because the language and runtime allow the exact same null for them that we've had since v1.

Heck NVTs came in v2. null having this meaning had been in both if these places since almost the beginning. We literally added it to the system at the same time we did generics. They're baked in as deeply as we did that.

[khm1600]

While the same exhibits senseless warnings

static void NotNull_NullableAnnotated ( [NotNull] string? s )
{
} // Warning CS8777 Parameter 's' must have a non-null value when exiting.

NotNullAttribute Class:

Specifies that an input argument was not null when the call returns.

In other words, when the arg is null, the call does not return. Therefore:

static void NotNull_NullableAnnotated([NotNull] string? s)
{
    if (s is null) throw new Exception();
} // no CS8777

[jnm2]

@Uzivatel919 Yes, what's senseless is not the warning. What's senseless is putting that attribute on that parameter.

[Joe4evr]

Is it senseless? The new ANE.ThrowIfNull helper method is implemented in exactly that way.

[deep-outcome]

@jnm2, in fact I was expecting error for putting the attribute to not by ref parameter. This is not there. Instead there is senseless warning. On the other I found it out by mistake as you took hint.

[deep-outcome]

@Joe4evr, No, it is not. I missed the conceptuality. I got impression that these ones are designed to denotes contract about outputs but they are leveraged also to denotes contract about inputs. Handy.

[jnm2]

@Joe4evr You're right, and it's strange that I forgot that given that I've made use of it when annotating two assertion frameworks.