[Discussion] Default values in a generic context

[avin-kavish]

This isn't exactly a proposal but an open discussion regarding the complications of making the following possible.

public void Foo<T>(T value)
{
    if (value == default(T)) // <--- compile error
}

The question as to why this will not compile was asked on StackOverflow and the answer seems to be there is no IL opcode to map the == operator to the appropriate equality comparer at run-time. So while default(T) on it's own can be evaluated at run-time, value == default(T) cannot.

I'm no language expert. I don't even know whether the above is true. Aren't operators resolved at JIT? Are operators only resolved at compile-time? I find it hard to believe to be the case since operators can be overloaded, inherited and polymorphasised which means they have to be resolved just in time. If that's the case and if generic methods are also JITed to methods that accept concrete types at run-time, why can't the combination of the two, value == default(T) work? The steps I see for this to work are

• Encounter call to generic method using a concrete type
• Start building a variant of it that accepts the concrete type
• Encounter value == default(T)
• Evaluate default(T)
• Map == operator to relevant equality comparer
• Build equality expression
• Throw if == is not defined for that type

I guess the problem begins in the statement above when throwing is brought into the picture, I will open the debate with the argument that since only a generic default value equality comparison can throw, and not anything else, it is okay.

I do also have some concerns regarding the behaviour of the default literal surrounding generics,

public void Foo<T>(T value)
{
    if (value == default(T))   // <--- compile error

    if (value == default)    // <--- runs, but how can this behaviour be defined if the above can't be?
}

If T is a reference type and value is null this comparison returns true. If T is an int, the IL code still does a null check which returns false when value = 0, the default. Isn't that incorrect by definition? This behaviour seems to be counter intuitive and confusing. Is this intended due to some circumstance that I'm not seeing?

To summarise,

• Let's discuss the complications of making value == default(T) possible
• Let's address the inconsistency between value == default and value == default(T)

Now that I get to the end of this write up perhaps the latter bears more importance.

Credits to this discussion here

[svick]

Aren't operators resolved at JIT?

No, they are not. One reason for that is that different languages handle operators differently.

I find it hard to believe to be the case since operators can be overloaded, inherited and polymorphasised which means they have to be resolved just in time.

Overloading is resolved at compile time (with the exception of dynamic). Operators can't be virtual, since they're always static, so I'm not sure what do you mean by "inherited and polymorphasised".

if generic methods are also JITed to methods that accept concrete types at run-time

This is also not quite true: generic methods are JITted only once for all reference types.

I will open the debate with the argument that since only a generic default value equality comparison can throw, and not anything else, it is okay.

I don't understand, why would that make it okay? I think it's never okay for == to throw.

I do also have some concerns regarding the behaviour of the default literal surrounding generics, […] Isn't that incorrect by definition?

That does look like a bug to me. Based on dotnet/roslyn#24913, I think that code should also produce a compile-time error, just like the default(T) version.

---

One more question: why do you want this work, when EqualityComparer<T>.Default.Equals(value, default(T)) already works?

[avin-kavish]

That does look like a bug to me. Based on dotnet/roslyn#24913, I think that code should also produce a compile-time error, just like the default(T) version.

This PR was merged one year ago, why is this bug still in our compilers? Do we need to update something? Or do I need to file a new bug somewhere?

Overloading is resolved at compile time (with the exception of dynamic). Operators can't be virtual, since they're always static, so I'm not sure what do you mean by "inherited and polymorphasised".

That was just speculation to see what was going on, haven't really read up on operators.

generic methods are JITted only once for all reference types.

This is fine, since all reference types have a default of null, it's not going to get in the way.

value == default(T) My understanding of why this doesn't work seems to be off obviously, . Can you state in your own words why this doesn't work?

EqualityComparer<T>.Default.Equals(value, default(T));                value == default(T)

If you put these two expressions side-by-side, and ask me to pick one, I'm definitely going with the one with the equal sign in it. The syntax is cleaner, the intention is clear.

I just got an idea on what would make this possible. Generic constraints on operators. i.e.

public void Foo<T>(T value) where T : ==
{
    if (value == default(T)) 
}

Problem solved?

[svick]

This PR was merged one year ago, why is this bug still in our compilers? Do we need to update something? Or do I need to file a new bug somewhere?

I think an issue should be filed at dotnet/roslyn about this, yes.

value == default(T) My understanding of why this doesn't work seems to be off obviously, . Can you state in your own words why this doesn't work?

Because there is no reasonable sequence of IL instructions that does the right thing.

If you put these two expressions side-by-side, and ask me to pick one, I'm definitely going with the one with the equal sign in it. The syntax is cleaner, the intention is clear.

You're right. But having some way to achieve what you want, even if it's not ideal, makes the feature less useful to have.

I just got an idea on what would make this possible. Generic constraints on operators. […] Problem solved?

I think that's a good idea, and it's actually being worked on, in an even more general form called "shapes": #164. If shapes were implemented, I think you would get what you wanted.

[canton7]

Note that this isn't so much about default values at all - it's about the equality operator.

== can mean a number of different things in C#.

For reference types, == means reference equality by default (and the compiler emits an IL instruction which compares the references), but this can be changed if one of the types involved defines its own == operator. The user-defined operator is a static method (it cannot be overridden), and the compiler gives it the special name op_Equality. When the compiler sees == used between two types, and of them defines an == operator which could be used, the compiler doesn't emit an IL instruction which compares the references but instead emits a call to that static method. So an == that you see in your code between two reference types might be compiled to a reference comparison, or it might be compiled to a static method call.

There's a very good reason that user-defined operators are static methods in C# (whereas many languages make them virtual instance methods), and that is to avoid problems where a == b (which calls a virtual method on a) doesn't give the same result as b == a (which calls a virtual method on b). See Eric Lippert's blog for a full discussion. The compiler chooses the right method to call, based on the compile-time types of both types.

Value types are similar, except that == can only mean a call to a user-defined == operator. That is, the compiler always needs to be able to find a == operator at compiler-time, and always emits a call to a static method. (I'm ignoring Nullable<T> for simplicity).

So the JIT knows nothing about ==. It knows how to compare two references (if it's given an IL instruction to compare two references), or it knows how to call static methods and it might be given a static method to call which is actually op_Equality, a user-defined == operator. All calls to == are resolved at compile-time by the compiler.

Now you can see the problem. In a generic method, there's no way for the compiler to know what types are involved at compile-time, and so it can never find a suitable user-defined == operator to call. The only thing it can do is to emit an IL instruction to compare references. It would be possible to make this "work" for value types, but it would always return false, which would really confuse people.

So in an unconstrained generic method (i.e. there's no where T : class or where T : struct constraint), you can't compare two instances of T using ==: if T were a reference type then == would mean reference equality sure, but there's nothing that can be done for value types. Remember that there's no way for the compiler to look for user-defined == operators at this point. The exception to the rule is == null -- for reference types this is a reference comparison, and for value types this always returns false.

If you add the constraint where T : class, then you get to use ==, and it always means a reference comparison.

If you add the constraint where T : struct, then == is verboten, and you can't even write == null.

Hopefully that explains why things are the way that they are. Primarily the issue is that operator resolution is done by the compiler, but generic methods are expanded by the JIT.

Note that C# does have an object.Equals(object) method, which calculates equality by calling a virtual method. This doesn't involve the compiler in the same way that == does, so it is OK to call a.Equals(b) where a and b have generic type. EqualityComparer<T>.Default.Equals(a, b) is more or less doing the same thing, but with extra null-checks (if a is null), and calling an implementation of IEquatable<T> if one exists. Note that this is technically entirely different to calling == -- an object == operator and Equals method may do entirely different things.

If you want to do a reference comparison of two generic variables (and always return false if they are value types), then use (object)a == (object)b.

---

I agree that allowing value == default but not value == default(T) seems like an error. value == default will always return false for (non-nullable) value types.

[mburbea]

At first, I thought this was equally bizarre that this happened.

Foo<T>() => default(T)==default;
...
Foo<int>(); // false
Foo<int?>(); // true
Foo<string>(); // true

But, then I realized in this comparison, since T does not define an == operator (and cannot as it's generic). It's defaulting to the == operator defined on object. So really this is just saying default(T)==default(object), which for value types is always false.