Allow Pseudo-Overriding of Null-Coalescing Expression via Member-Based-Predication

[TheFanatr]

Allow Pseudo-Overriding of Null-Coalescing Expression via Member-Based Predication

This is an alternative proposal for the allowance of the null-coalescing ?? operator to be overridden via letting the target expression's type programmatically dictate what the behaviour of the expression should be, thus indirectly overloading the operation of the operator. This would see the "Null-Coalescing Operator" be renamed to something like "the Validation Operator" to better fit it's use.

target expression ?? fallback expression
where target expression decides whether or not the expression should use itself or the fallback value.

This is useful because it allows for much easier value validation, and could eliminate magic behaviours. Also, once C# 8 launches with opt-in nullability, this operator could still have a major use.

Explanation

The general preface of this proposal is that instead of changing the current behaviour of the expression for any one type by default, the predication of whether or not the value of the target expression should be coalesced to is decided by the implementation of the type of the expression via a specific member. This could be done in 2 similar ways.

This member could be implemented on the Object and ValueType types and made overridable to derived types like the ToString method is. This way, the Object class could hold a default implementation that just checks if the object is null, and the ValueType implementation could just always return false, keeping compatibility with most codebases that currently use the expression.

Definition of Sample Class

public class T
{
    public int IntegerMemberOne { get; set; } = 0;

    /* Coalescence Validity Predication Member */
}

Possibility One

There should be a member that is reflectively called if existing on the type that allows the type to dictate whether or not any instance of a type should coalesce to the fallback or not. Basically, there should be a Coalesce method implemented on the object that checks if the state is invalid.

// On type T
public static bool Coalesce(ref T typeTObject) => typeTObject is null || typeTObject.IntegerMemberOne == 0;

This would also allow for the modification of the value in case it is needed such as in cases where something on the object needs to be calculated or state-changed, but the object is immutable.

Possibility Two

The general idea of possibility two is that the validity-based coalescing expression should attempt to cast the target expression to a bool-typed Boolean value and if the result is true, the object is considered to be in a valid state and the expression is not coalesced to the fallback expression. This is the opposite functionality to possibility one. The implementation of a coalescence predication member in this manner should appear as follows.

public static explicit operator bool(T typeTObject) => !(typeTObject is null) && typeTObject.IntegerMemberOne == 0;

Behaviour

With respect to the definition of the coalescence validity predication member from either possibility, the expression should operate like so, with said member being called to determine whether or not the fallback expression should be evaluated and presented as the value of the overall expression based on the convention of the possibility from which the member definition originates.

// With respect to same type T
T object = new T { IntegerMemberOne = 4 } ?? new T { }; // Result: fallback expression
T object2 = new T { } ?? new T { IntegerMemberOne = 4 }; // Result: target expression

[Joe4evr]

This is nothing more than a comment for #2020. Please keep the discussion in one place.

[TheFanatr]

@Joe4evr that's not true. #2020 asks to allow overriding of the ?? operator, whereas this asks for a change in functionality that checks with a member on the target expression's type for whether or not the value of the expression should be used. The functionality of the operator is not directly overriden by the type, rather it is simply consulted. The difference is that allowing it to be overriden would mean that the return type of the expression, the other parameters, and overall functionality could be changed. That is not the case with this proposal, which only suggests that that a type should be able to provide a predicate for whether or not the value of the expression is used, as previously mentioned. The reason that this should be preferred is because allowing the operator to be fully overloaded would result in the ability to change the type of either parameter of the expression which would break the behaviour of the expression as a ?? b ?? c is supposed to be the same as a ?? (b ?? c) which could no longer be the case if the operator was overloaded to have a different type in the fallback expression parameter.

[YairHalberstadt]

I will point out that the performance costs of adding a virtual method to object are huge. There is no way that is going to happen. It would also require CLR changes.

A number of quite respected language designers think it was a mistake to even make Equals, ToString and ToHashCode virtual method on object.

I would suggest you rework your proposal so it doesn't rely on that.

[TheFanatr]

@YairHalberstadt interesting point. I did however intend to mention that the addition of these members to the actual base types is optional, but would provide consistency. To an extent, I agree with the idea of not having virtual methods on base types, but not having equals would be taking it too far, but that is a sidebar. What I was more going for is an effect similar to how any type instance can be destructed into a ValueTuple instance as long as the type defines a properly-formed Deconstruct method. I actually consider the way type deconstruction is implemented to be kind of messy, but I think that it serves as a much better basis for implementing something like this than an overloadable operator does. There are so many overloadable binary operators that making this one overloadable would have it lose it's purpose; the core intent of the operator is to decided whether or not the first expression presents a value that has a valid state, and if not, to use something else, and this completes that without changing the purpose beyond recognition.

[YairHalberstadt]

Well the issue with Equals is that it confuses two separate concepts. Value equality, and reference equality.

Value equality only makes sense for objects that define it. So I would make ReferenceEquals a non virtual method on object, and use an interface to indicate value equality.

[MgSam]

Can't you just use an extension method to do this?

• I do not find your suggested usage of ?? intuitive, as the question mark is intimately related to nullness in C#.
• Operator overloading should be a last resort; only used when the benefits clearly outweigh using a straight method call (doing math on user-defined types being the best example). Your use cases seem like something most people would rarely want to do.

[Austin-bryan]

It makes zero percent sense for the null collase operating to do anything besides null collasing, espically if it doesn't even involve null at all

[TheFanatr]

@willard720 well the whole point is to extend it; the purpose of the operator is to be able to expressively sub out null-evaluated expressions that would indicate an invalid/unset state, and replace the result with some fallback. In my opinion it makes sense to allow types to have some say of what counts as pseudo-null or an invalid state for that type.

[TheFanatr]

@MgSam I agree with you on not allowing direct overloading, as is why I made a separate proposal to #2020, and while I understand that *?*-related operators generally hint at dealing with nullness, the basic idea is that an invalid state on an instance of an object is more/less equivalent to null, so I am suggesting that this operator could be allowed to respect pseudo-null states. Also, I don't exactly understand what you mean by using an extension method; yes you can create a generic extension method that allows coalescing in the way that I've proposed to allow the operator to work, but the whole point is to have syntax sugar for it and optimization. By that logic, you could say that there's no point to have he current null-coalescing operator.

[CyrusNajmabadi]

Since hte value is not actually null, htere's a perfectly good solution you can provide: just add a method (or an extension method) on your type. You can then just do:

myVal.OrIfNull(otherVal)

[TheFanatr]

@CyrusNajmabadi you realize that your suggestion argues against the current null-coalescing operator as well; it could be implemented as an extension method by the end-user, but the syntax sugar was added anyways, so why not extend it to be more useful and still be related to its original purpose? Especially now that C# 8 is introducing opt-in nullability, this would be even more useful.

[CyrusNajmabadi]

; it could be implemented as an extension method by the end-user,

It could have. But, in general, people do not tend to like 'instance looking' members being allowable on null instances. If that were not the case, i would have been ok with an extension-method solution.

For real instances that can represent invalid states, it's still fine to have an instance call on it.

[YairHalberstadt]

@CyrusNajmabadi
An extension method would evaluate the expression used as a parameter whatever happens. The null coalescing operator would not.

The extension method would have to accept a function, at which point it's clearer and easier to just check for the invalid case manually.

Nonetheless, I do not support this proposal, as adding too much complexity for too little benefit.

[Austin-bryan]

@TheFanatr So, you mean for example, -1 counting as null as it's an invalid age, for example? I can see the use, but it's misleading. What if you had an int? and were using null as data not collected and -1 as not born yet (or any other scenario where you want to know if it's null or pseudo null specifically)?

I think it would be more useful to have a different operator than ?? as right now, all that does is expand into an if statement, and we can rely on that fact. Imagine someone overloaded it to call 40 methods without us knowing?

Maybe something like ~? or ~?? to show it's not really null, but it might as well be.

By that logic, you could say that there's no point to have he current null-coalescing operator.

Also, we have the null collasing operator because it's so common, and is shorter than Foo foo = bar.ButIfNull(fooBar); and more readable.

If this feature was added, I actually wouldn't be able to use it in any of my existing code, because the only time I could imagine using pseudo-null is in data type structs, but now we can just make them nullable and have real nullable usage. Also, having a pseudo-null class makes no sense.

Can you give an example where using nullable value type won't get the job done?

Even in my example, I can get that job done using just int? and having a property defined as HasBeenBorn => Age > -1.