Why is unconstrained T? allowed when T is not decorated with notnull?

[TahirAhmadov]

class Foo<T>
{
  public void Bar(T? t) // should be an error? why is this allowed?
  {
    ...
  }
}
var foo3 = new Foo<string>();
foo3.Bar(null);
var foo4 = new Foo<string?>();
foo4.Bar(null); // same as foo3 above, which is incorrectly consistent, despite T being different

I looked at the LDMs here and here and found no mention of using notnull to prohibit unconstained nullable generics. Was it ever brought up?

[jnm2]

It could make a lot of sense. Imagine SomeCollection<T> where T : notnull might definitely be the right thing to do. Yet, you'd still want a T? GetValueOrDefault(int id) method that returns T?.

There's no necessary connection that I see that says where T : notnull and T? are incompatible. It's similar to where T : struct, and T? works along with that just fine. Imagine T? being something that fits around T, even in the case where T is not a struct type. A T? potentially contains a T.

As the author of the same class, don't write T? if you don't mean it. The same would hold for where T : struct as it has for many years.

[jnm2]

Having that method on the class is a mistake; I would not want to have it.

I disagree, and I think the BCL does as well. You use OrDefault methods either when there is no confusion or when you don't need to tell the difference apart. Both situations seem common to me. .NET ships many of these: FirstOrDefault, Nullable<T>.GetValueOrDefault, dictionary GetValueOrDefault. The idiomatic C# operation ?? default (or ?? 0, etc) is often useful for the same reason.

TryGetValue is also useful, but it's clumsy at the call site and I often refactor it to GetValueOrDefault in cases where default(T) can't have been in the collection or else where it doesn't matter.

(You'll sometimes also see an extension method OrNull to pair with the OrDefault method, where the OrNull extension method is further constrained to T : struct. This is also nicer to use than TryGetValue.)

[TahirAhmadov]

Having that method on the class is a mistake; I would not want to have it.

I disagree, and I think the BCL does as well. You use OrDefault methods either when there is no confusion or when you don't need to tell the difference apart.

That's the issue, really - it's one more way to somebody to shoot themselves in the foot.

Both situations seem common to me. .NET ships many of these: FirstOrDefault,

Yes, IEnumerable<T>.FirstOrDefault has the same problem, but it existed in .NET since before NRTs, so it's legacy. Whereas unconstrained nullable generics are a new addition.

Nullable<T>.GetValueOrDefault,

Here, it's where T : struct, so it's irrelevant to my question.

dictionary GetValueOrDefault.

Same as FirstOrDefault - except this one was added recently, so it doesn't have the excuse of being legacy.

The idiomatic C# operation ?? default (or ?? 0, etc) is often useful for the same reason.

I never had to use this, but even when it is, it's explicit - you are telling the system that for you int? null is the same int 0; and not implicit.

TryGetValue is also useful, but it's clumsy at the call site and I often refactor it to GetValueOrDefault in cases where default(T) can't have been in the collection or else where it doesn't matter.

Yes, and I see the value in GetValueOrDefault pattern myself - I use it all the time. However, to be able to use this pattern, T has to be known to be notnull, otherwise it creates an ambiguity.

(You'll sometimes also see an extension method OrNull to pair with the OrDefault method, where the OrNull extension method is further constrained to T : struct. This is also nicer to use than TryGetValue.)

I have those myself, yes; in fact, I have both OrNull with where T : class, and OrNullStruct with where T : struct. That way, at least in my own code, I avoid this confusion.

[jnm2]

However, to be able to use this pattern, T has to be known to be notnull, otherwise it creates an ambiguity.

This is simply not true. The ambiguity is fine in the majority case, and OrDefault can be used without T being known to be notnull. The BCL's opinion on this is clear, and every case I've seen so far seems to back this up.

[jnm2]

For example, this kind of thing is not uncommon for me to do:

if (items.FirstOrDefault() is { } item)
{

Inside the if block, two things are explicitly clear: there is at least one entry at the beginning of the list, and it is also not null. This works equally clearly whether the list element type is Item or Item?.

[TahirAhmadov]

Empirically you have a point - most of the time developers know what they mean. However, that also applies to NRTs in general. I went through a lot of my code (not all of it, due to time constraints) to make it NRT-compliant, and in many cases I noticed how I avoided NREs by being careful with initialization sequence, etc. - using other proven patterns. However, that doesn't mean NRTs are useless. Similarly, here I understand that most developers are able to use OrDefault methods and they know what they mean - and that's exactly what NRTs were meant to avoid - leaving it to the developer to remember. Obviously NRTs in general solve a lot more than this case, which is more of an edge case, but it's a similar thing.

[koszeggy]

Yes, and I see the value in GetValueOrDefault pattern myself - I use it all the time. However, to be able to use this pattern, T has to be known to be notnull, otherwise it creates an ambiguity.

Instead of foobaring let's see some meaningful example:

// notnull for TKey, whereas TValue is not decorated by anything
class SomeDictionary<TKey, TValue> where TKey: notnull 
{
    // TValue? is totally meaningful here, regardless of any constraint
    public TValue? GetValueOrDefault(TKey key} => ...;
}

Both SomeDictionary<int, string?> and SomeDictionary<int, string> make perfect sense (you get a warning if you try to add null to the second one). But GetValueOrDefault can return null in both cases so its return value must be TValue?. Why do you think that "TValue has to be known to be notnull"? I see no ambiguity here.

[CyrusNajmabadi]

That would communicate the intent more clearly,

I think the point is that for many (myself included), the intent is clear and this behavior does match what is wanted.

In other words, a ton of the time I do want the absence of a mapping to be treated equivalently to a mapping to the default value.

Yes, in the cases where I care about the distinction I can do more explicit checks. But if I don't care (the common case), why would I jump through hoops?

[jnm2]

@TahirAhmadov

public static TValue?* GetValueOrDefaultNullable<TKey, TValue>(this SomeDictionary<TKey, TValue?> This, TKey key) where TValue : notnull

You realize you have firmly supported the case that T? is a legitimate thing to use when T : notnull, right?

[TahirAhmadov]

Yes, in the cases where I care about the distinction I can do more explicit checks. But if I don't care (the common case), why would I jump through hoops?

The extension method I suggested solves that problem - just use the GetValueOrDefaultNullable method 90% of the time where you don't care about the distinction. By no means I'd want anybody to write out the TryGetValue && is null check every time.

[TahirAhmadov]

You realize you have firmly supported the case that T? is a legitimate thing to use when T : notnull, right?

Yes, that was the entire point of my opening post, wasn't it?

[jnm2]

Oh, I was confused. I thought you were saying the exact opposite. I still disagree though, but now it's easier to think of cases where T? makes sense since where T : notnull is so rarely right for me.