Allow null-conditional operators and null-coalescing operators to be overloaded (see issues)

[Lorenzo501]

These four operators have to be overloaded in the Unity game engine (very popular) but cannot, and is therefore making all four operators incompatible with Unity objects. The workarounds to use those operators on non-Unity objects and at the same time taking action on the code style suggestions for these operators with Unity objects, requires clumsy extensions and in my case even an (Unity) editor utility to initialize a singleton with early access for editor scripts if it's null.

This all just to get rid of the code style suggestions and keep things as nice and consistent with those new operators as it can be. These workarounds aren't standarized either! So most Unity game developers do not even use the new operators at all and are simply turning off the code style suggestions for it. Please make these operators available to everyone by making the exception to have them become overloadable.

[HaloFour]

IMO this is not a language concern. Unity is violating the CLI soecs and behavior in ways that break how null is supposed to work. This should be fixed in Unity, not by adding language features to paper over Unity problems.

[HaloFour]

I also don't think opening multiple discussions for polls is appropriate for this repo.

[Lorenzo501]

There was no poll for this issue yet but apparently the only way to allow Unity game developers to use the new operators like everyone else, is to make them overloadable so that the Unity engine developers can make them compatible with Unity objects. I'm not really here to discuss it any further, I'm merely bringing the issue to light and having people vote on it. It has been discussed for a long time now on the Unity forum and after reading a whole lot of it, I concluded that Unity can't really do anything about it atm. And that leaves the Unity game developers unable to use these operators on Unity objects, while they do get suggestions both for and against it (which is obviously unfair and unpleasant to deal). Game developers don't want to work around the issue, they want to use those operators. So if Unity engine developers can't do anything about it, I don't see how that is any better. It should work for everyone. 😅

[HaloFour]

This has been discussed here as well and the general consensus seems to be that the language designers aren't interested in amending the language specifically because one runtime did something very incorrectly which affects everything that expects to be able to use reference equality.

[HaloFour]

I'll also note that the issue doesn't stop at the null-conditional or null-coalescing operators. The problem is that Unity has broken all of reference equality, and that affects both every feature in C# that depends on reference equality as well as everything in the runtime that depends on reference equality. Adding a couple of overloadable operators doesn't fix the problem, it just papers over it in a way that perpetuates the broken state, complete with the warts that go along with that. No amount of overloading or language shenanigans changes how the runtime interprets reference equality, and thus this friction will always come up and always be surprising.

[jnm2]

A poll worded "improve the life of" versus "screw" does not inspire confidence in the results.

[RikkiGibson]

We know people are experiencing pain as a result of the current interaction between Unity's object design and C#'s design. We're interested in understanding that pain better and what could be done to improve things. We'd just ask that people refrain from using inflammatory language.

[jaredpar]

I've locked this discussion as the format of the question is not appropriate for this repository. Labeling an option as "NO (screw game developers)" is a disingenuous choice.