Can we let null being inferred as just object ?

[Thaina]

It happen when I write generic method that can put any object to be serialized. And when I create tuple

public static void TestWriteLine<T>(T value) => Console.WriteLine(value.ToString());
////

TestWriteLine(null);
var pair = ("key",null);

I expect both case to accept null as object. But it error cannot be inferred from the usage instead

I think it could be useful if we could treat null as just object for inferring type in most case. Especially in serializing and interop with other system

[yaakov-h]

null is by definition the absence of an object. Absence has no type.

[bondsbw]

These cases don't clearly demonstrate why this is a disadvantage.

The first example is better for not allowing null, as it prevents an inevitable runtime exception.

[DavidArno]

With nullable reference types on the way, even if such an idea were adopted, then that default type would need to be object?, not object.

But leaving that aside, I agree with @bondsbw: your TestWriteLine(null) example argues against you as you are asking for a feature that makes it easier to get NRE's at runtime and I find your tuple example to be non-compelling too.

[Thaina]

@DavidArno @bondsbw I think that should not be a responsible for function to help us avoid null like that. It fine if it translate to object? and also CLR would not recognize it anyway

The example just demonstrate what kind of code that error. The advantage is as I said above, serializing and interop with other system. Such as I was working with JSON and GoogleProtoBuf. Both allow serialize null value

public static Google.ProtoBuf.Value CustomSerializeValue<T>(T value)
{
    if(value == null)
         return new Google.ProtoBuf.Value() { NullValue = true };

    // Do something with T value

    return Google.ProtoBuf.ValueSerializer.Serialize(value);
}

The actual code I written are more complex but in the end I just want to write TestWriteLine(null); instead of TestWriteLine((object)null);

[GeirGrusom]

Couldn't just null be an expressible type instead? I don't really fancy that overload resolution should arbitrarily select object when null is passed.

[DavidArno]

@GeirGrusom,

That was my initial thought too. But where does it fit in the type hierarchy and how would the language and runtime cope with casting between "NullType" and all other types (taking into account invariant collections etc)? I suspect the cons far outweigh the pros on this one.

[yaakov-h]

@GeirGrusom so should null.GetType() return an actual type instead of a NullReferenceException? If so, breaking change...

[DavidArno]

@yaakov-h,

Is "this code used to crash; now it works!" really a breaking change? 😀

With the move to nullable ref types, and the near inevitable adoption of T? as C#'s own maybe/option type, supporting null.GetType() and null.ToString() etc makes a lot of sense. I really do not see how going from throwing an exception to returning a meaningful value in either case can be considered a breaking change, but some folk write super weird code and so it wouldn't surprise me if it were seen as such.

[yaakov-h]

I’m would not be surprised if somebody out there somewhere has a function like:

static bool IsNull(object o)
{
    try
    {
        o.ToString();
    }
    catch (NullReferenceException)
    {
        return false;
    }
    return true;
}

[Thaina]

@DavidArno Well, it is. There could be a logic that rely on NullReferenceException to throw out to above layer and continue. If it not crash then it would change behavior, something like @yaakov-h example above. But with more complex logic

@yaakov-h I don't expect null.GetType() would be able to run. But we could and should always check in generic method for handle null value anyway. Generic method always able to pass null value, just not a direct null

And when it was check for typeof(T) it would be just an object

[iam3yal]

Can't you specialize like this?

public static Google.ProtoBuf.Value CustomSerializeValue(object value) => CustomSerializeValue<object>(null);

Then you can just do exactly what you want without casting?

CustomSerializeValue(null);

Alternatively,

public static Google.ProtoBuf.Value AnotherCustomSerializeValue<T>(T value) where T : class => CustomSerializeValue<T>(null);

About the tuple I don't know maybe, although, I agree with @yaakov-h on this and the docs state this exactly:

The null keyword is a literal that represents a null reference, one that does not refer to any object. null is the default value of reference-type variables.

[DavidArno]

@yaakov-h,

"but some folk write super weird code..." 😁

In my view, anyone writing such horrific code as that deserves to have it break. It might teach them a lesson in how to write better code that way 😆

[yaakov-h]

I agree, but can you convince the LDM?

[Thaina]

@eyalsk Well, I just think about this issue in the same time as Tuple so if we would fix I think it should be fixed together

Yes, we can do as you have shown but it would be unnecessary if it just allowed to do. And it was a bug prone to have boilerplate code to maintain

[Thaina]

@DavidArno As the law standard state that we should not punish people who do illegal thing in the past when the action was not yet defined as illegal. Coding standard should be the same

[HaloFour]

Since C# 1.0 the language specification has required that attempting to call an instance member of a null reference would throw an exception. That's not a requirement or a limitation of the CLR, which allows you to invoke a non-virtual instance method with a null this value. This is why the C# compiler always uses callvirt when invoking instance methods (with few specific exceptions). I'd say that changing this would be quite a big behavioral change for the language.

And remember, non-nullable reference "types" does not introduce new types into the language. The type will always be the reference type, the (non-)nullability is a property of the variable and flow-analysis.

[Thaina]

@HaloFour I don't try to propose that calling any member of null value should return anything or not throw exception

What this issue mean is compile time error when infer a null keyword itself for generic and Tuple (internally Tuple is also generic?) should be allowed as just being object or object?

var pair = ("key",null); // pair should just be Tuple<string,object?>

[GeirGrusom]

@DavidArno null already has a type. All we know about null's type is that it's implicitly convertible to any nullable type.

@yaakov-h
My suggestion was to allow void Serialize(null value). Not that GetType() or whatever else would behave differently. I met the exact same issue as @Thaina and my solution was to write a SerializeNull() method. But it would be a lot cooler if I could write Serialize(null).

[Thaina]

@GeirGrusom I think, maybe, null is a type in dotnet but never be a type in C# and this 2 is difference

C# language spec since 1.0 strictly forbidden usage of type null even dotnet contain it, that maybe what he mean. We might use C# in other place such as compiled to webassembly

[DavidArno]

@GeirGrusom

null already has a type. All we know about null's type is that it's implicitly convertible to any nullable type.

Ah, I didn't know that. Thanks for the info.

[iam3yal]

@Thaina Any reason why (string key, object value) pair = ("key", null); wouldn't be good enough? then you can even give it proper names whereas with var you can't.

I guess what I'm saying is

1. If the tuple is small enough then you can just avoid type inference and give the fields synthetic names that describes the pair.

2. If the tuple is large then it might be good idea to consider a struct.

3. Type inference exists to make it easier to consume tuples so in your case it would be something like this:

void Main()
{
	var x = Foo();
}

(string key, object value) Foo() {
	return ("key", null);
	
}

As opposed to something like in the example you gave var pair = ("key",null) but you can also do this (var key, object value) = ("key", null).

[Thaina]

@eyalsk Linq and all generic extension method that could automatically infer type

var objs = array.Select((item) => (key:item,value:null));

And using var as a pattern make me feel more comfortable because I use var almost everywhere

And also because sometime it not just string but longer type name

var key = someThing.GetLongNameTypeKey();
(SomeType.WithVery.LongPath.AndLongName key, object value) pair = (key, null);

// vs

var pair = (key, null);

[iam3yal]

@Thaina (var key, object value) pair = (key, null) should work though.

[vladd]

@GeirGrusom null has no type: https://ericlippert.com/2013/07/25/what-is-the-type-of-the-null-literal/

[MkazemAkhgary]

If you want to pass null to generic function, use default keyword or cast to whatever type you like.

[yaakov-h]

Default is target-typed. I don’t believe you can use it in this context either..

[TheUnlocked]

If you're using a generic, there's no reason to only ever pass in null. If you're only going to pass in null, don't make the function generic. If you aren't only going to pass in null, assuming the type of null to be object could cause even more problems with generic types not matching up.

This just feels like it could cause a lot of issues when someone forgets to specify their generic and then ends up spending hours searching for why their program thinks they're trying to implicitly convert between object and whatever their type is. Typing in a few extra characters (and even fewer if you have good templates and autocomplete) seems like a fair price to make that not happen.

[IS4Code]

You would be discriminating all those poor strings and bool?s if you started to prefer objects.

[Thaina]

@IllidanS4 I don't think it discrimination because object is parent of both anyway

[AustinBryan]

(T, object) pair = ("key", null);