default(ImmutableArray<T>) boxing

[TahirAhmadov]

Currently, this throws an exception:

ImmutableArray<int> ia = default;
IEnumerable e = ia;
_ = e.GetEnumerator(); // exception
// ChatGPT gave me this helper method to avoid exceptions:
bool IsBoxedDefaultImmutableArray(IEnumerable src)
{
    var t = src.GetType();
    if (t.IsValueType
     && t.IsGenericType
     && t.GetGenericTypeDefinition() == typeof(ImmutableArray<>))
    {
        // unbox and read IsDefault
        var prop = t.GetProperty("IsDefault");
        return (bool)prop.GetValue(src);
    }
    return false;
}

I'm not sure if this can be changed at this point, but I was thinking about what the correct behavior would be in a perfect world, and I had an idea that e would become null above. This would allow non-aware receivers of IEnumerable to do a simple null check instead of the reflection helper above.
That raises the question, how do we determine which structs become null when boxed? I immediately remembered Nullable<T> and how it's special cased for this purpose. Could we potentially come up with a generalized approach?

interface IBoxesToNull
{
  bool IsNull { get; }
}
struct Nullable<T> : IBoxesToNull where T : struct
{
  bool IBoxesToNull.IsNull => !this.hasValue;
  // etc.
}
struct ImmutableArray<T> : IBoxesToNull
{
  bool IBoxesToNull.IsNull => this.IsDefault;
  // etc.
}

If the above is not feasible for any reason, can we add a special non-generic interface?

interface IValueTypeCollection
{
  bool IsDefault { get; }
}
if(e is not IValueTypeCollection { IsDefault: true })
{
  _ = e.GetEnumerable();
}

PS. It's also possible this is a bug (.NET 8) and it's supposed to act as an empty collection.

[elgonzo]

ImmutableArray<int> ia = default;
IEnumerable e = ia;

bool b1 = ia == null;       // produces true
bool b2 = e == null;        // produces false

If this can't be changed anymore to make more sense, ImmutableArray<T> will always be remembered as the "a bit how ya goin" type...

[colejohnson66]

An uninitialized ImmutableArray<T> is designed to act just like a normal uninitialized T[] - including how any operation on one is a “null reference exception” instead of “invalid operation exception”. So, default(ImmutableArray<T>).GetEnumerator() and default(T[]).GetEnumerator() have the exact same behavior.

It’s not “actually” boxing to null (as @elgonzo shows), but boxing to a legitimate heap object that, through C# code, throws NullReferenceException when you do anything with it.

It’s an illusion. And it breaks when you poke at it. The null comparison is a lie. One that makes an uninitialized struct act like an unallocated class.

[TahirAhmadov]

I guess your point is that it's not a bug and is by design? I can believe that - in fact I thought so myself (I mentioned the possibility of it being a bug just in case).

And I understand the mechanism at play here - it boxes the default struct - and that's what I mean in OP: it would be cool to change it so that instead of boxing the default struct, it converts to null - like Nullable<T> does.

[elgonzo]

It would be nice to have a CLR treatment of ImmutableArray<T> like Nullable<T>, not only because it would provide the convenient lie that a boxed ImmutableArray<T>.Default equals null, but also might allow is pattern matching like ia is null.

Granted, it's not completely comparable to Nullable<T>, because Nullable<T> doesn't implement any interfaces, whereas ImmutableArray<T> does. But i am no expert in CLR magic and machinations, so i have no clue to what degree that would complicate things...

[colejohnson66]

The CLR specification states that the only possible struct that can box to null is Nullable<T>. Nothing else. While I’m sure the runtime could make another “here’s where we differ from the CLR spec” bullet, it doesn’t seem to be worth it from a cost point of view, but that’s just me.