Overload Resolution, Span<T> param vs pointer param, ambiguous for null keyword

[sunkin351]

So, a little context... I'm working with a binding around the Vulkan Graphics and Compute API, and some of its methods have Span and pointer overloads. I need to pass a null literal for this, but it's somehow ambiguous between Span<T> and T*?

Span<T> has an implicit conversion from a T[] array (which can notably be a null reference), causing this, but shouldn't it use a direct match to null T* instead of causing this ambiguous resolution?

public static void MyMethod(Span<int> span)
{
}

public static unsafe void MyMethod(int* ptr)
{
}

. . . .

MyMethod(null); //This is somehow ambiguous

[Scott-Caldwell]

but shouldn't it use a direct match to null T*

According to the C# language spec, the conversion from a null literal to a pointer type is also an implicit conversion.

In an unsafe context, the set of available implicit conversions (Implicit conversions) is extended to include the following implicit pointer conversions:

• From any pointer_type to the type void*.
• From the null literal to any pointer_type.

[mikernet]

Wow, how did I not realize for 20 years that you can implicitly cast a null literal to a value type as long as the value type has exactly 1 implicit reference type conversion defined?

That's really strange. I don't know how I feel about that being allowed to begin with...it's just too weird to be able to set a value type to a null literal value, i.e. Span<int> x = null. It also stops working if you add a second implicit conversion from another reference type or if the implicit conversion is defined on the reference type instead of the value type. I understand why that is, but those nuanced behavioral issues make me wonder why even bother allowing it.

[sunkin351]

I agree, its not exactly intuitive... And I'd rather there not be an implicit conversion between null and a struct type.