Proposal: Allow null conditional (?.) and null coalescing ()?? operators to be overloaded

[Alexees]

I'm asking this in favour of the Game Engine Unity. Since the core engine is written in C++ and scripts are written in C#, == and != are overriden. This means even though serialized fields (public or SerializeFieldAttribute) which are reference types, get an instance of the corresponding C# class created during construction. In these cases those operators still return null because there has not been any C++ equivalent constructed.
Now since ?. and ?? have made their introduction, they cause a lot of confusion as you have to know when they can be applied and when they cannot. Here, they cannot. Visual Studio shows the variabled as being null, but they're still chosen despite this fact and cause NullReferenceExceptions afterwards.
If they were overridable they could just implement the same logic and we all could use this syntax without hesitation.

[PathogenDavid]

For the confused reactions: Unity has a type called UnityEngine.Object which is used as a base class for all engine-specific objects that have a representation in both the Mono and C++ side of things. (That's my understanding anyway, it might be more complex than that.)

These objects can be null-ish when they exist in Mono but don't exist in the engine.

Unity overrides the equality operator to reflect this behavior (Implemented by UnityEngine.Object.CompareBaseObjects as seen in operator==/operator!=). Since safe navigation and null coalescing are equivalent to checking obj is null rather than obj == null, the operators are not called so the zombie object is treated as not null.

---

In my opinion, this issue is a weird quirk of how Unity treats objects in general. I don't think it's really something that makes sense to change in the language.

IMO, if this were done, it'd make more sense to allow overriding operator null similar to how we can override operator true and operator false today.

---

@Alexees What are you doing where you keep running into these zombie objects? I always knew they existed in Unity, but I've never actually run into them in practice.

Visual Studio shows the variabled as being null

This sounds like a poor design choice in the Unity tools for Visual Studio or in the UnityEngine.Object.ToString implementation. They should probably show "Zombie" or something similar to emphasize that they aren't null, but they aren't usable either.

If you happen to be running into this with MonoBehaviour or ScriptableObject instances, you should try overriding ToString to look something like this:

public override string ToString()
    => this ? base.ToString() : "<Zombie>";

[Alexees]

Consider this piece of code

[SerializeField] private GameObject go;

private void Start()
{
  GameObject current = go ?? gameObject;
  current.AddComponent<T>();
}

breaking into the line that uses the null coalescing operator, in the case go is not set in the Unity Editor, hover/preview the value of it will show it as null, but the operator still chooses it as the assignee for current. This results in the next line throwing the exception.

[HaloFour]

That seems like a behavior that could awkwardly rear its head all over the place resulting in NREs at runtime. I'd suggest that maybe this is something that Unity should resolve through its runtime rather than having the language attempt to gloss over it?

[PathogenDavid]

Oh weird, sorry for assuming you were doing something unusual. I will note that this doesn't happen with references to other components (MonoBehaviour) or custom serialized assets (ScriptableObject). From my quick test, it happens with references to UnityEngine.Object, GameObject, and Material. I'd expect it to probably happen with all other asset references too.

I suspect this is also why I've never run into it. I generally use references to specific components on other game objects rather than references to the game objects themselves.

Also, slight nit-pick here: It throws UnityEngine.UnassignedReferenceException, not NullReferenceException.

It's also worth noting that zombie instances do look slightly different in the debugger:

(References with the value of "null" instead of null are the zombie ones.)

---

I agree with @HaloFour. This is something that Unity should change rather than C#. The deserializer shouldn't assign these zombie objects to unassigned fields.

However, I don't see Unity changing this anytime soon. I wouldn't be surprised if there's an actual reason for it too.

---

It's not pretty, but you can workaround this quirk using self-reflection in your Awake method. Example here. (EDIT: Updated, see this comment for details.) (Use at your own risk. Not tested outside of the editor.) You can add that class to your project and make sure all of your script components inherit from FixupNullsBehaviour instead of MonoBehaviour. If your script needs to use Awake, make sure you call base.Awake();. I tried to use ISerializationCallbackReceiver, but you can't check if an object is a zombie from the deserialization thread.

[ufcpp]

#147

[Alexees]

@PathogenDavid thanks for your insights and thoughts
@ufcpp thanks for redirecting me to original existing post

[CyrusNajmabadi]

breaking into the line that uses the null coalescing operator, in the case go is not set in the Unity Editor, hover/preview the value of it will show it as null

Roslyn only shows 'null' for constants that are set to null. Can you be more specific about what is showing the value as 'null?

[PathogenDavid]

@CyrusNajmabadi What he was seeing is Unity returns the string null for UnityEngine.Object.ToString when an object is internally null-ish in Unity. (See the image in my earlier comment.) What he's seeing isn't Microsoft's fault.

[PathogenDavid]

@Alexees

I asked @xoofx on Twitter and he was able to provide some insight into why Unity works this way.

Short version: The fake null values are an editor-only feature to display more helpful error messages when you use a null-ish reference:

The important takeaway here is that this only happens in editor builds. In standalone player builds, the references are literally null as expected:

As such, the workaround is only necessary for editor builds. I've updated my workaround to reflect this.

Also do note that nullish Unity objects can still happen in the case of destroyed objects. So this workaround is only applicable when you're dealing with a freshly deserialized object. Proper language support like #147 would still be necessary if you want null-coalescing to work in these situations. (Although I'd argue that if you are keeping references to dead Unity objects then you have a bug anyway.)

[yaakov-h]

Did Unity ever make a decision or are we still rolling on inertia?

Considering that the .NET Framework debugger (and I think .NET Core too now?) can tell you which variable was null when you get a NullReferenceException without resorting to zombie object hacks, this seems like something Unity should improve/fix, not the language team.

There's a similar issue with is null pattern-matching and I expect that this will become an even more pervasive issue once recursive patterns lands in C# 8.0.

[PathogenDavid]

(Micro disclaimer up front: I say "Visual Studio" a lot here when "A modern .NET debugger like Visual Studio" might be more accurate.)

@yaakov-h

Did Unity ever make a decision or are we still rolling on inertia?

There was no update in the comments, but they are apparently riding on interia. That article was published 4 years ago before Unity 5. My test runs performed in this thread were performed with Unity 2018.3.0b6 (that's a recent beta release, although not the latest.)

---

Considering that the .NET Framework debugger (and I think .NET Core too now?) can tell you which variable was null when you get a NullReferenceException without resorting to zombie object hacks

It's maybe worth mentioning for the sake of perspective that Unity doesn't let Visual Studio (or other debuggers) debug exceptions uncaught. Exceptions are always swallowed by the engine and appear in the console:

(Yes this is infuriating. It's my #1 issue with Unity as a game engine.)

Unity only shows the exception message. I believe the faulting reference getting shown by Visual Studio is a Visual Studio feature.

One exception is you can tell Visual Studio to always break when a NullReferenceException is thrown, then it will go to Visual Studio for debugging like you'd expect. However, the faulting reference isn't shown like you'd normally expect. I presume this is that information is provided by the runtime. Unity uses Mono, so it might be a Mono limitation.

---

For reference for any Unity users wandering in here (or people like me who forgot Visual Studio does this), this is the feature @yaakov-h is referring to:

---

this seems like something Unity should improve/fix, not the language team.

Strong agreement here. I was pretty disappointed to learn that they considered and didn't take the breaking change in Unity 5. Quirks like this are why I'm not a huge fan of Unity.

---

There's a similar issue with is null pattern-matching and I expect that this will become an even more pervasive issue once recursive patterns lands in C# 8.0.

Unity is currently stuck on C# 6.0 and .NET Framework (equivalent) 4.6, so they don't even have pattern matching at all yet. (The latest Unity betas have support for Roslyn, C# 7.3, .NET Framework 4.7.1, and .NET Standard 2.0. That all is supposed to drop by the end of the year.)

I'm not sure if this quirk will cause any more problems than it already does. It mainly comes up when fields with specific types are serialized as null and later deserialized.

[yaakov-h]

I presume this is that information is provided by the runtime. Unity uses Mono, so it might be a Mono limitation.

Yep, it's information exposed by the debugger APIs starting with .NET Framework 4.6.2.

https://docs.microsoft.com/en-us/dotnet/framework/whats-new/#Debug462

[Austin-bryan]

Unity is a very bad game engine. This is a problem that Unity needs to fix, and not one that the entirity of C# needs to suffer for. The last thing we need is unknowingly having .? calling methods behind our backs.

[cjsio]

Sure it's simplistic, though I see no reason it has to be complex. I appreciate your approach looking at this from a business perspective and from open-source projects with many maintainers. From this same viewpoint, when either of these entities has a codebase class that overrides the == and/or != operators, I don't see either party being black-boxed or prevented from debugging or understanding the functionality of that class.

Additionally, is there anything in the project or in VS's or VS Code's IDE that inherently shows the programmer in a codeblock each place an (objectA == objectB) equality check is using overridden behavior?

If not, then neither should the null coalesce and/or null check operators need this. If so, nothing should stop us from likewise showing that the null coalesce or null check operator is employing overridden operator logic.

The point is, we don't need to deviate from our existing operator override paradigms to introduce this language feature, and maintainability for any entity type should remain exceptional.

[CyrusNajmabadi]

The way you phrase it makes the request sound like implementing additional overridable operators is a grandiose process impacting every other facet of the language architecture

Yes. Imo, it would be. null and null-checks have deep meaning for the language. As an example, you can pattern match against null.

I really have no idea why unity works this way. There is already a perfectly reasonable .net representation here. It is null. Just like null is the representation used for a nullable value type.

Unity has an underlying concept of 'disconnected/disposed '. It seems to want to treat that as null, while projecting through an actual non-null value. Either it should just be a disconnected/disposed state on the object, and the object can respond to normal lookup . just fine. Or, if it wants to be treated as if it was null... Then it should just be null.

[cjsio]

Unity has an underlying concept of 'disconnected/disposed '. It seems to want to treat that as null, while projecting through an actual non-null value. Either it should just be a disconnected/disposed state on the object, and the object can respond to normal lookup . just fine. Or, if it wants to be treated as if it was null... Then it should just be null.

At the very least, we want to treat that like null, even if projected through a pseudo-null object. The C# code we write is semantically equivalent to a null check method chain: if the left-side evals to null, kill the method chain. The only difference is that we need it to also kill the method chain when the (underlying C++) object is disconnected/disposed, which is easily solved with a null check operator override. But until/unless that point, our C# code is more verbose for no readability benefit.

[CyrusNajmabadi]

Unity has an underlying concept of 'disconnected/disposed '. It seems to want to treat that as null, while projecting through an actual non-null value. Either it should just be a disconnected/disposed state on the object, and the object can respond to normal lookup . just fine. Or, if it wants to be treated as if it was null... Then it should just be null.

At the very least, we want to treat that like null, even if projected through a pseudo-null object.

You can do that. Just have the methods on it check that they're in that state and return an appropriate value.

There's no need for a special operator because there's no null ref you need to avoid from the call site. As you have an actual instance, it can receive the message and respond to it.

The C# code we write is semantically equivalent to a null check method chain: if the left-side evals to null, kill the method chain.

But it isn't. ?. is necessary because the null ref is otherwise unavoidable. There is literally no instance to handle the method call. That is not the case when you have an actual instance.

But until/unless that point, our C# code is more verbose for no readability benefit.

Your c# could should end up less verbose. Because you don't even need ?., you can just do ..

[cjsio]

There's no need for a special operator because there's no null ref you need to avoid from the call site. As you have an actual instance, it can receive the message and respond to it.

We need a reproducible use case now.

I have a go object which only shows as "null" string literal in VS debugging, and the tree nodes do not expand at all.

Syntactically, I am expecting go?.GetComponent() to not execute the .GetComponent() call.

However, even though the object C# object is not set to the formal null value, Unity knows that it is "null". This means the null-check operator fails to honor this traversal-layer-enabled definition of null.

So when running, having this null-check operator currently behaves exactly like this line of code when the null-check is omitted. Instead of skipping the method chain call (which is what I'm trying to do with the null-check operator), it throws an exception telling the programmer to check if the object is null; this will only function properly with an override definition.

But it isn't. ?. is necessary because the null ref is otherwise unavoidable. There is literally no instance to handle the method call. That is not the case when you have an actual instance.

See above use case.

Your c# could should end up less verbose. Because you don't even need ?., you can just do ..

Nope, because now my working solution has to be either the very verbose

Transform t = null;

if (go) {
    go.GetComponent<Transform>();
}

or the ternary option

Transform t = (go ? go.GetComponent<Transform>() : null);

instead of the most concise and clear standard language option:

Transform t = go?.GetComponent<Transform>();

which would be most preferred, and just requires the ability to override the null-check operator.

[juliusfriedman]

While we are at it why don't we also allow custom operator overloading across the board.... heck why not even totally custom operator$?

.][><_/=÷×+)(*&%$#@!

®...

Tl;dr...

Operators are useless in c# when I can ref up a method to perform the same logic with less overhead.

The benefit IMHO comes when the jit can elide certain check and or create better runtimr code e.g. as it does with == / ceq on occassion, that being typed...

If operator overloads could be used with ref operators I could live with that enhancement as well...

[capnslipp]

So am I correct in the assessment that the developers of Unity are too stubborn to change the way they're doing things, and the developers of .NET are too stubborn to allow any additional functionality, so the end-result is that end-users of C# in Unity are stuck with a sh＊tty experience— while all the developers who can actually improve things would rather point fingers and blame and shade.

This would be the perfect time to throw shade at both Unity and .NET for the rampant bugs and antiquated APIs both have suffered from over the years, but… that's just mean-spirited.  The reason why I'm willing to be a d＊ckhead here is to make it clear that if using your platform is a sh＊tty experience, people will leave— regardless of whether it's your fault or not.  I know I have mostly abandoned Unity & C# as much as I can for alternatives I prefer— Unreal, Godot, C++, Rust, Swift.

Grow up and come up with solutions.  There's plenty can't in the above comments— the same attitude that's all common among the core .NET/C# developers' blog posts over the years.  If you can't then I and others can abandon you.  Again, I'm sorry about I have to be a d＊ckhead, but sh＊t rolls downhill, and I'm tired of being sh＊t on.

[CyrusNajmabadi]

Would it have really been too much to ask or caused any problems anywhere to have both Array and List have both properties, with one aliased to the other? Seriously, W.T.F.

This would be something you could recommend over at dotnet/corefx. Thanks.

[CyrusNajmabadi]

but C# has been seriously destructive to my mental health on too many occasions

You need to step back. You're not dealing with pragmatic product decisions in a healthy manner. No language out there satisfies its entire audience all of the time. And pretty much all of us have worked in environments where the language we had to use made decisions that we didn't like. It's part and parcel of being a software developer.

Personally, my experience has had me use actively for the past 20 years: C++, Java, ObjectiveC, Swift, Python, Go, C#, VB, TS, JS (and many others). Every single one of these languages has made decisions that have actively made my professional life harder and have caused extra work to be necessary when compared to hte others. That's just life. I strongly ask that you step back, take a breath and not allow yourself to get so mentally hung up on these things. It's never going to be beneficial for you or your career. It will also interfere greatly with your attempts to see change happen. After all, if it causes you to interpret decisions as "hostility" and the like, then you'll only catch yourself up in a vicious cycle of frustration and anger.

[Alexees]

Wow, that was a long debate. Sorry for everyone if my proposal got you headaches.
May I ask what you think the next steps will be? Hearing that not many have had problems with this also makes me think that most, including me, adopted explicit == and != checking early on and on the first appearance of a stringed null thought "dang, forgot to do the right check" instead of "why is that even".
I might be wrong but I think I've heard Unity is rewriting their whole Engine in C# due to their newly acquired DOTS System.
Anyways, I think ==, !=, ?? and ?. not behaving the same way is a problem and needs to be addresses. If people were relieved that the last two were checking for the underlying null then maybe two new operators that actually do the overridden version could be a solution, bloating the language though. Or a compiler flag that let's you choose what kind of check they perform...

[CyrusNajmabadi]

May I ask what you think the next steps will be?

At this point the feature request has been made. It will be up to the LDM to decide if they want to take it.

At hte very least though, i would recommend putting forth a full proposal. i.e. one that outlines precisely what change one would like to see in the language and covers important details like: "is htis a breaking change?" It should also go in depth into potential alternatives and why they are not acceptable.

The proposal can optionally come wiht an implementation PR. That can help but is def not required.

If a good proposal can be made that meets the goals of the C# team and substantively provides a reasonable path to get there, it has a change. If the proposal actively goes against C# goals (like 'no breakin changes') or doesn't address serious alternatives, then i don't think it can be taken seriously.

For example, it would need to seriously address why solutions with extension-methods/analyzers aren't acceptable. Those would be avialable now at costs 3-4 orders of magnitude less than changing hte language. the value of this work would have to demonstrate that it was getting that sort of payoff to warrant the investment into it.

TLDR: feature requests that are effectively no more than "i don't like this, plz make this better" won't go anywhere. The feature request has to be in depth and has to act similar to a thesis where the problem is effectively stated and the solution is well defended across the board.

[Alexees]

I'm just a Dev, not a language designer so you don't consider myself capable of providing a proposal with in depth details about it being a being change or not.
All I know is that the operators cannot be used when overriding == and !=.
So unless someone else can, this Proposal has come to an end.

[jamesford42]

Overloading ?. would be very clean syntax for types which encapsulate a reference-by-id to an object that is not necessarily resolved yet, but should be on demand. I want to treat the wrapper type as if it were an actual object of the inner type, which i could do by attempting the resolve and returning null or the other type when ?. operator occurs.

[cjsio]

I agree that I'd prefer this very clean and concise syntax inside Unity projects, since we're already very used to using it outside of Unity development. Thank you for your comment; I bet a lot of us have this same desire for language syntax and operator consistency.

[yuyang9119]

As a developer with over 10 years of experience using Unity, I believe that Unity made some mistakes in the early design of its API, including overloading the == operator. But from a language perspective alone, it seems unreasonable to allow overloading == while not allowing the customization of other operators related to null reference checks (imagine being able to overload == but not customize Equals).

On the other hand, considering the complexity of equality comparisons in the C# language and runtime, another thought I have is that perhaps we shouldn't make it more complicated... Let's stop the confusion here and moving forward, let's write code using the recommended approach. I've heard that Unity is addressing this issue, so we'll wait and see.

Additionally, I've noticed that some similar proposals have been locked, is it because you already have conclusions about such proposals?

[jamesford42]

Note that my use case shows something not unity specific, and also very clearly not the usual usage of ?. (so, not ambiguous) because it would be used on a struct representing some other class type object, and the current alternative is having a method call like .Get()?. everywhere.

In fact I want a method call, that I get to write, but the syntax could be a lot nicer.

[Smooth-Tools]

You can use this asset from the asset store to use the null conditional and null propagation operators safely on GameObjects: https://assetstore.unity.com/packages/tools/utilities/smooth-operator-271378

[cjsio]

You can use this asset from the asset store to use the null conditional and null propagation operators safely on GameObjects: https://assetstore.unity.com/packages/tools/utilities/smooth-operator-271378

Looks great but pretty pricey for implementing a way to overload the null conditional and null coalesce operators.

As a developer if you can override the == and != operators, you'd think just for that one type that you could also override ?. and ?? to standardize their behaviors, such as like:

public static bool operator ?(UnityEngine.Object x) {
    // ...
}

public static bool operator ??(UnityEngine.Object x, UnityEngine.Object y) {
    // ...
}

And if you don't explicitly override these, then they'd continue working as expected: all existing code continues to function exactly as it historically has. In C# we haven't been able to override these operators previously, so moving forward anyone wanting to use this would be explicitly opting in, such as Unity only with their UnityEngine.Object but nothing else.

Providing this extensibility support should genuinely have no out-of-the-box negatives, and would only break existing code if developers override these operators with arbitrary "bad" definitions - but likewise, overriding the == and != operators with arbitrary "bad" definitions would also obviously "break" existing code all the same.

Yet if one developer is disorganized to the point of writing a "bad" operator overload, perhaps without considering inheritance, and ends up fighting against oneself, why should that prevent an organized developer from being able to write calculated operator overloads in a given use case? The developers using Unity quite literally need only to override UnityEngine.Object's null check and null coalesce operators.

If you don't want to override these operators, then don't - and still, having added this support, presumably everybody wins. Right?

[jamesford42]

I think bringing up unity, despite the original poster having done so, it's just going to be a distraction for getting something like this actually done.

I think the next step is someone to actually write a full proposal. Actually question for someone more important than me around here: what is the next step here?

[theunrepentantgeek]

Usually, someone from the Language Team needs to Champion the idea - to lend it support and to shepherd it through the process.

Without a champion, there's no point in a design doc.

[cjsio]

I think bringing up unity, despite the original poster having done so, it's just going to be a distraction for getting something like this actually done.

Unity is just a very tangible use case. Development is always a balance between theory and pragmatism, and in this case, there is a very real pragmatic need, if a very large portion of game developers are to enjoy this quality of life in C# itself.

Usually, someone from the Language Team needs to Champion the idea - to lend it support and to shepherd it through the process.

Without a champion, there's no point in a design doc.

Does the (current) lack of a supporting Language Team member negate the following?

Yet if one developer is disorganized to the point of writing a "bad" operator overload, perhaps without considering inheritance, and ends up fighting against oneself, why should that prevent an organized developer from being able to write calculated operator overloads in a given use case? The developers using Unity quite literally need only to override UnityEngine.Object's null check and null coalesce operators.

[cjsio]

So, what practical downside is there to raising quality of life for extensibility here?

it muddies the definition of null, and null-tolerant operations, which is exactly what the ? operators are for. Today it is extremely nice that the semantics are entirely clear. Either the value is non-null and you get one side, or hte value is null and it operates specially.

I do like this response. I think it's the strongest case against allowing these operators to be overridable. But, I will raise you one. Isn't allowing == to be overridable likewise muddying the definition of equality? You're changing a comparison of strict equality of the full object and all properties. Overriding == redefines equality in a non-standard way in your specific project, and we already support that, for good reason should the use case need arise.

I'd like to apply that same logic to the null coalesce. Unity's C++ to C# traversal layer already has a "muddied" definition of null, and being able to override the operator would bring consistency and uniformity for us developers who are used to (and love!) the simplicity, directness, and clarity of using null checks and null coalesce operators - in all of our C# projects, not just most of them.

[CyrusNajmabadi]

Isn't allowing == to be overridable likewise muddying the definition of equality?

No. because == wasn't created to distinguish null vs non-null. It was to allow comparison. ?. and ?? were distinctly created to deal with the problems with null. Namely that calling . just blows up on it... because it's null. It was not ever intended to be used for any other purpose than gently handling nulls entering the system.

[cjsio]

Isn't allowing == to be overridable likewise muddying the definition of equality?

No. because == wasn't created to distinguish null vs non-null. It was to allow comparison. ?. and ?? were distinctly created to deal with the problems with null.

I didn't say == was created to distinguish null vs. non-null. I said == was created to determine equality. I then applied the same "muddying the definition of the operator's original intended purpose" logic to the already overridable equality operator.

Namely that calling . just blows up on it... because it's null. It was not ever intended to be used for any other purpose than gently handling nulls entering the system.

Right. And we have some specific use cases now where a C# object is not null, but its traversal-layered C++ object underneath is disposed of, which will mean the null check operator fails to identify when executing the chained method call will throw an exception. This unfortunately makes the non-overridable null check operator useless to us for objects of these types.

All we want is the option to apply the same overridable logic to more existing operators for standardization in projects that currently don't benefit properly from those existing operators and their intended functionality.

[CyrusNajmabadi]

I said == was created to determine equality.

Right. And thus there's no muddying. It was created to determine equality and it still does that.

Right. And we have some specific use cases now where a C# object is not null, but its traversal-layered C++ object underneath is disposed of

That's not null. That's 'is disposed'. If you want to test for .IsDisposed and do something special with that, that's fine. But that's not anything related to null-ness.

which will mean the null check operator fails to identify when executing the chained method call will throw an exception

That seems to eb an impl detail. You could have your object see htat it was disposed and chain as appropriate. That's not somethnig possible with null as the method never even executes.

[cjsio]

Right. And thus there's no muddying. It was created to determine equality and it still does that.

There absolutely is muddying. The logic behind overriding the equality operator is inherently diluting what traditional equality strictly means. If that's not muddying, then we have a muddy definition on the term "muddying".

That's not null. That's 'is disposed'. If you want to test for .IsDisposed and do something special with that, that's fine. But that's not anything related to null-ness.

It's a disposed object in the C++ side, which, if I recall correctly, debugs in VS as a "null" string literal on the C# side. But with how the references work across the language-traversal layer, my understanding is the engine can't (or doesn't want to?) set the C# object strictly back to formal null. Perhaps this is to prevent memory leaks or other negative consequences. Unfortunately this is where I can't delve into further specifics, but back on the C# side, the null check and null coalesce operators are quite literally the perfect operators to override to handle this use case pain point.

Likewise, no other operator (that I'm aware of) is suitable to address it. Instead we're currently required to surround a line of code with if (thisObject) { } instead of simply employing a null check.

[CyrusNajmabadi]

This seems to just be a debugger display for the item. It's not actually null. If it was then ?. would work for it.

Unity knows that it is "null". This means the null-check operator fails to honor this traversal-layer-enabled definition of null.

That's a choice unity has made in its debugger display. The debugger could have a empty string display as "null" in the debugger as well, but it wouldn't be.

Nope, because now my working solution has to be either the very verbose

No, it doesn't need to be that. I'm saying: go.GetComponent<Transform>() should just work. And if go is internally this special sentinel-null-value then it can return a null Transform instead of throwing.

[HaloFour]

That's because the method throws. The suggestion is that the method could be changed to not throw in this case. Or an alternative method could be provided, e.g. GetComponentOrNull which would not throw. If that method were an extension method, it could even handle the possibility of the wrapper class being null.

[CyrusNajmabadi]

I guess you're ignoring what we already went through, because I gave #2020 (reply in thread) where using just . throws.

You can change that to not throw. You said that yourself. You then said you didn't want to do that, and were incredulous that i actually thought that was hte right way forward. I insisted i was being serious and that that was the better route here.

[cjsio]

You can change that to not throw. You said that yourself. You then said you didn't want to do that,

I'd said I could create a subclass and inherit the overridable null check operator there, if that's available in the language. In theory though, I could do that or implement methods marked as overridable.

Well, Unity certainly won't use [the overridable null check operator] if it's not available. But it'll be way easier to convince Unity to implement it if it's available inside the language. Also, if I need to, I can just create a new class that inherits Unity's main object class, and implement the null check there. So again, I have the ability to fix this issue in my own projects even if Unity doesn't (immediately) adopt the strategy - but only if I can override the null check and null coalesce operators [bolded for relevance to current reply].
— @cjsio

Then do that :-)

You can just subclass them and make it so that the normal methods work in some fashion when in this disconnected state.
— @CyrusNajmabadi

I was saying I could implement the null check override operator in that subclass, in your theoretical if Unity refused (or took a long time) to implement the overridable operator(s) in their own base class.

So to do that, my only prerequisite is for the language to have the null check operator overridable.
— @cjsio

Specifically on overriding all these methods, before assessing true feasibility, I did ask if you really considered that the better solution, which highlighted our differing prioritizations.

and were incredulous that i actually thought that was hte right way forward. I insisted i was being serious and that that was the better route here.

I accepted your position as genuine after reading that next response you gave. I just wanted to ensure we were thoroughly considering the negative impact on the implementation layer.

But yesterday I determined the subclass is completely not viable for Unity's GameObject class because it is sealed. The Component class, isn't sealed, but doesn't have virtual on any of its methods such as .GetComponent(). Also, this would of course require casting logic for a less readable solution throughout the C# logic.

In short, you are focused on avoiding changes to the language without a ubiquitous demand, to the point where (even large) subsets of projects and workflows may or will incur significant footprint increases via subclasses/inheritance/whatever is needed to maintain this prioritization.

In contrast, I am focused on automating my responsibilities, and having to maintain subclasses beyond a single operator override method is inherently and substantially less ideal of a longterm solution.

@HaloFour:

That's because the method throws. The suggestion is that the method could be changed to not throw in this case. Or an alternative method could be provided, e.g. GetComponentOrNull which would not throw. If that method were an extension method, it could even handle the possibility of the wrapper class being null.

I did document the use case; I'm very acquainted with it throwing haha. Unfortunately with the sealed class and lack of virtual on methods, I can't change the methods nor override them (or if overriding still works, I incur hiding warnings etc.).

Having reached the impasse above, extension methods may now be the best option, pending any punctual moves from Unity on this in the mean time. It's still not ideal, plus I'd prefer to stick with Unity's documented methods for core engine functions including .GetComponent(), but I understand that the implementation layer is what will continue to suffer here.

[CyrusNajmabadi]

I'd said I could create a subclass and inherit the overridable null check operator there, if that's available in the language. In theory though, I could do that or implement methods marked as overridable.

If we added such a feature, it would mean that every null check everywhere would need to be recompiled to lookup to see if this overridden operator existed. Null checks would go from a literal single asm instruction (or, honestly, just a trap of a null-deref), to actually having to be a method call. This is a real non-starter.

But yesterday I determined the subclass is completely not viable for Unity's GameObject class because it is sealed

Then how would an 'overridable null check' help? The object is sealed. So you wouldn't be able to subclass and add this new null-check operator override.

It's still not ideal, plus I'd prefer to stick with Unity's documented methods for core engine functions including .GetComponent(), but I understand that the implementation layer is what will continue to suffer here.

I don't understand what possible solutoin you think we could provide here. Fundamentally we keep running into: the only solution is for unity to change. Combined with: unity does not seem interested in changing this.

No amount of us adding lang features changes that equation. And, even if we did all this work, on the guess that unity might use it (which seems super unlikely given that htey've done absolutely nothing else ot make this scenario better), it still comes with a perf hit for literally 100% of all programs ever in existence. So we're degrading the entirety of the .net ecosystem on a speculative presumption that one small part of hte ecosystem might use it.

This is not any sort of sensible path forward.

[cjsio]

If we added such a feature, it would mean that every null check everywhere would need to be recompiled to lookup to see if this overridden operator existed. Null checks would go from a literal single asm instruction (or, honestly, just a trap of a null-deref), to actually having to be a method call. This is a real non-starter.

But yesterday I determined the subclass is completely not viable for Unity's GameObject class because it is sealed

Then how would an 'overridable null check' help? The object is sealed. So you wouldn't be able to subclass and add this new null-check operator override.

That reply from me was all historical context for discussion lurkers, no new discussion, mainly to answer your "You can change that to not throw. You said that yourself. You then said you didn't want to do that," statement. It wasn't that I "didn't want to" but that it was way more nuanced, and later determined not even possible via the sealed issue. Also wanted to clear up the "genuinely" question because it was a serious, legitimate question, not trying to be rude.

I do appreciate the added specificity though of "Null checks would go from a literal single asm instruction (or, honestly, just a trap of a null-deref), to actually having to be a method call. This is a real non-starter."

It's still not ideal, plus I'd prefer to stick with Unity's documented methods for core engine functions including .GetComponent(), but I understand that the implementation layer is what will continue to suffer here.

I don't understand what possible solutoin you think we could provide here. Fundamentally we keep running into: the only solution is for unity to change. Combined with: unity does not seem interested in changing this.

Unfortunately, yes, despite me wanting better quality of life in the implementation layer in these Unity projects, I do agree with you having fleshed out this discussion prior.

No amount of us adding lang features changes that equation. And, even if we did all this work, on the guess that unity might use it (which seems super unlikely given that htey've done absolutely nothing else ot make this scenario better), it still comes with a perf hit for literally 100% of all programs ever in existence. So we're degrading the entirety of the .net ecosystem on a speculative presumption that one small part of hte ecosystem might use it.

This is not any sort of sensible path forward.

My takeaway from all this discussion in terms of desired language features is that, completely forgetting Unity, it would still be nice and beneficial to have a usability check operator, where we can define a custom method eval to see if a chained expression should terminate or continue. As stated by I believe both of us at this point, does not address the Unity issue, but just as a general language feature, would be a welcome addition from devs like me.

Cheers @CyrusNajmabadi and others, thank you for your time and the elaborate, civil discussion we've been able to have on this.

[SSM240]

?. and ?? were distinctly created to deal with the problems with null. Namely that calling . just blows up on it... because it's null. It was not ever intended to be used for any other purpose than gently handling nulls entering the system.

If this is truly meant to be the only purpose of ?., then why do nullable value types support it?

Consider the following simple snippet:

string s = null;
Console.WriteLine(s?.ToString() ?? "is null"); // prints "is null"
Console.WriteLine(s.ToString()); // throws a NullReferenceException

This works exactly how you'd expect - the ?. operator kicks in for a member access that would otherwise throw.

Now consider the exact same thing with a nullable value type set to null:

int? n = null;
Console.WriteLine(n?.ToString() ?? "is null"); // prints "is null"
Console.WriteLine(n.ToString()); // does not throw, prints an empty line

Clearly the ?. and ?? operators are treating this value as if it were null. And yet... trying to access the method directly doesn't throw, because it was never truly a null reference (it's just an instance of Nullable<int> with HasValue set to false).

So nullable value types are, effectively, doing what you don't want to allow developers to do: overloading the concept of being null to work more smoothly with other language features. Granted, it's doing some special compile-time transformations that wouldn't necessarily work with custom operators (on sharplab.io you can see that it's transforming the n?.ToString() access into num.HasValue ? num.GetValueOrDefault().ToString() : null at compile time), and the concept of nullable value types is directly built into the language so you could argue it gets some privilege, but to me it still demonstrates that this idea of "the operator should only ever work with true null references that are actually null for reals" doesn't seem to be quite true.

[HaloFour]

Given that Unity is stuck on an older version of C#, it's not like any language changes will help here anyway. You won't be able to adopt them. As Unity is considering reworking their APIs (including reconsidering those implicit operators) as they migrate to .NET 8.0, it feels like a much better opportunity to fix the underlying problem with how Unity objects are intended to work rather than perpetuating the problem and hoping that eventually C# will adopt this language change and that years later Unity might actually support that version of C#.

[CyrusNajmabadi]

The difference is my use case scope is substantially more in line with the existing functional behavior of ?. in practice.

Not afaict. The existing functional behavior is to be resilient to something being null. Your case is one of being disconnected. Which, afaict, is much more akin to an object being disposed, but wanting to still do functions on it without it throwing an ObjectDisposedException.

[CyrusNajmabadi]

Recognizing this, I am shifting towards asking for a new "usability check" operator, to not blur existing lines of the null check purpose

Sounds reasonable. Can you open a new discussion on that? We can work on the design and do some bikeshedding on possible operators that could be used for this purpose.

[CyrusNajmabadi]

Given that Unity is stuck on an older version of C#, it's not like any language changes will help here anyway. You won't be able to adopt them. As Unity is considering reworking their APIs (including reconsidering those implicit operators) as they migrate to .NET 8.0,

Strong agree. This is the case as well for any new "usability check" operator we might add.

[testonedev]

Recognizing this, I am shifting towards asking for a new "usability check" operator, to not blur existing lines of the null check purpose

Sounds reasonable. Can you open a new discussion on that? We can work on the design and do some bikeshedding on possible operators that could be used for this purpose.

Aye, that makes sense - new operator to keep the previous ones untouched, and extend with a new, alternative one for those in need

[BlinD-HuNTeR]

Given that Unity is stuck on an older version of C#, it's not like any language changes will help here anyway. You won't be able to adopt them. As Unity is considering reworking their APIs (including reconsidering those implicit operators) as they migrate to .NET 8.0,

Strong agree. This is the case as well for any new "usability check" operator we might add.

I won't dive into the discussion about Unity's "fake nulls", but I suppose there's a workaround for that, which not only "solves" the problem, but also doesn't require a newer language version:

Just remember that C# allows the || operator to be overloaded (just not directly, you have to override operator | and operator true, and together they become a short-circuiting implementation of ||).

With this approach, the Unity team could override the | operator to return the right side when the left side is nullish, and the true operator to return false for nullish values. Then, these scenarios will be enabled:

UnityEngine.Object obj = GetObjectA() || GetObjectB() //GetObjectB is called only if GetObjectA returns a nullish.
string s = (obj || null)?.ToString() //ToString is not called if 'obj' is nullish.