?? and ??= operators for non-nullable types

[tvidvei]

I just had a case where I wish I had an operator similar to the "null-coalescing" operators ?? and ??==, which could be used also with non-nullable types:

   public Color BackgroundColor {
       get => backgroundColor != default ? backgroundColor : StandardBackgroundColor;
       set { backgroundColor = value; }
    }

Here I would like to write the getter like the following, using the pattern I would use with nullable types:

        get => backgroundColor ?? StandardBackgroundColor;

Couldn't the null-coalescing operators be generalized to 'default-coalescing' operators that could be used both with nullable and non-nullable types by testing for equality with default(T) where T is the actual type?

Such a change would not break any existing code as far as I can see as the ?? and ??= operators currently can't be used with non-nullable types.

My proposal is then the following:

    a ?? b     // is short for:   a != default ? a : b
    a ??= b    // is short for:   if (a == default) a = b; 

This solution comprises the present semantics as 'default' is the same as null for nullable types.

[ufcpp]

#8718

[tvidvei]

I see, if I understand your proposal from 2017 right, that it is possible to create struct types where default is an invalid value, as demonstrated in your examples with PositiveInt. But wouldn't that be a case for a compiler warning if my proposed 'default-coalescing' operator is used, similar with your example with PositiveInt a = default(PositiveInt)?
And wouldn't non-defaultable types, after all, be very rare?

I noticed that in the thread following #8718, @sebas77 (on Dec 5, 2021), said:

I often need to warn the user that a struct must be initialised with the proper constructor and new TypeStruct() shouldn't be used. However, in my mind, I don't see why default(T) should not be allowed. I think they are two different things. default(T) shows an explicit intent, while new T() may be a mistake. My idea would be that new T() would generate a compiler error if not allowed, but default would always be allowed.

Although possible to construct a type T where default(T) is an illegal value, that should be highly discouraged, I think. Or perpaps prevented at compiletime.

In the case with System.Drawing.Color, this issue is solved by a field Color.State, in addition to the fields represening the color and opaquity. Both Color.new() and default(Color) returns a value Color.Empty with Color.State = 0, which means "Uninitialized", in contrast to Color.FromArgb(0,0,0,0) which is zero-valued color (black and full transparency) but "Initialized". Both are valid Color values, but doesn't draw anything.

To put the question the other way: Are there any need for non-defaultable types? Would't you always have the alternative of introducing an indicator of "uninitialized" similar to that of Color when you need it?

Best Regards,
Tor Vidvei