Usability Operator (similar syntax to null check operator)

[cjsio]

We had some in depth discussion on operators back in July on #2020

I was requested to create a separate discussion for the Usability Check operator idea.

Here's the guts:

Having a custom-definable usability check operator would be nice and beneficial, where we can define a custom method eval to see if a chained expression should terminate or continue. As a general language feature, would be a welcome addition, without impacting any existing operators (i.e. the null check operator remains completely untouched).

Proposed syntax: ??., !?., or similar

eg.

nonNullButNotChainableObject??.MethodCall(); // Usability Check operator

and optionally

object obj = nonNullButNotChainableObject !? defaultValueObject; // Usability coalesce operator

[timcassell]

Not sure about the syntax, but I like the idea of the operator. Maybe just prepend an extra ? to the null-check operators?

nonNullButNotChainableObject??.MethodCall(); // Usability Check operator
object obj = nonNullButNotChainableObject ??? defaultValueObject; // Usability coalesce operator

[colejohnson66]

Then just add more question marks to be extra sure! 🤣

object definitlyUsable = someObject ??????????? defaultValue;

In seriousness, I'm not a fan of pure question marks due to their similarity to the null-like operators. While the idea is similar, they're different enough IMO.

[KennethHoff]

I don't understand what it does. Presumably it's syntactic sugar for some other concept; could you update your post showing how your proposal compares to pre-existing solutions?

[cjsio]

Would like to emphasize that this is completely outside the use cases of Unity. This discussion surfaced regarding Unity, but in the same way that other syntax shortcuts like var lastItem = arrNumbers[^1]; and var lastFourItems = arrNumbers[^4..]; benefit us, this would give very similarly concise syntax instead a surrounding conditional or ternary, outside of Unity entirely.

@timcassell's elaboration is exactly on point: #8533 (reply in thread)

Please ignore Unity regarding this usability check operator proposal.

[HaloFour]

That's a theoretical use case, one that definitely does not warrant a special syntax. The only thing about the Unity use case that makes this remotely considerable is the size of the audience negatively impacted by it.

[cjsio]

Nobody "needed" var lastItem = arrNumbers[^1]; and var lastFourItems = arrNumbers[^4..]; but they are syntactical sugar. Nice option to have. There are tons of implementation cases where this operator could further simplify otherwise-unnecessary if statements because the given dev team implemented this proposed operator in the given codebase. Not "need" but helpful to have, absolutely.

[HaloFour]

Nobody "needed" var lastItem = arrNumbers[^1]; and var lastFourItems = arrNumbers[^4..]; but they are syntactical sugar. Nice option to have.

Slicing was a very highly requested feature, and one that many languages have.

[cjsio]

Nobody "needed" var lastItem = arrNumbers[^1]; and var lastFourItems = arrNumbers[^4..]; but they are syntactical sugar. Nice option to have.

Slicing was a very highly requested feature, and one that many languages have.

Yes, but the functionality itself isn't new. It's not something we couldn't do before. It's just more concise syntax. We've always had at the very least linq expressions, and you can manipulate arrays without the shorthand. But it's beneficial to have the shorthand syntax as an option no doubt.

[CyrusNajmabadi]

What's the use case?

As a general language feature, would be a welcome addition,

I would need to see examples of where this would be desirable in order to determine if this would be welcome or not. Specifically, I would need to strongly believe this is:

1. A pattern that appears commonly enough
2. The new syntax is substantively better
3. Users would move code to this new syntax

Could you expand upon the use case with real world examples?

[CyrusNajmabadi]

This API doesn't make sense to me. If you want this, an API would normally need to return something like an authorization token to pass along. So you'd really want to pass along something like an Authorized user which encapsulated all of that.

[cjsio]

That seems like an extremely contrived example. I've never seen a permissions system or permissions-related code that could be adopted to use this syntax,

Yes it was a rudimentary off the cuff example. So let's evolve it into a better real-world example case.

as you'd always want to validate the permissions and inform the user that they can't perform the operation long before the code reaches such business logic.

That depends on your codebase's business logic paradigm. There may be a series of actions that can be processed, and/or firing off events depending on permissions or any other pivot table data etc. There are a hundred different industry-specific scenarios and contexts that could implement this paradigm. You are not required to immediately return out of a given function or throw any Exception just because one sequential operation did not succeed due to inadequate permission values. Don't neglect silent failure paradigms. The more gracefully any codebase handles non-processed entities but without an unrecoverable cause, an exception may not be thrown. So likewise we want to consider batching of actions in any real-world paradigm.

Not to mention there's usually more than one permission.

Precisely why this operator can provide greater simplicity.

[cjsio]

@DanFTRX

Your example has just changed the behavior since now the "PerformElevatedAction" isn't checking 2fa anymore. So that doesn't really make sense.

Apologies, and good catch. I specified the true value parameter in the first bit but missed it when whipping up that use case. I've fixed that - thanks again. Although this does bring up the question of if parameters could be passed to the usability operator somehow. Guess not. So the usability operator implementation on the given object type would have to always check 2fa or never check it, not toggleable via parameter.

[cjsio]

@CyrusNajmabadi

This API doesn't make sense to me. If you want this, an API would normally need to return something like an authorization token to pass along.

I would view this less of an api and more of just the internal infrastructure of an existing codebase. Perhaps you already have the authorized token when in play. It's probably attached to the object instance (in this case user but could be any object). The current codebase as the authority doesn't need to pass a token around everywhere.

So you'd really want to pass along something like an Authorized user which encapsulated all of that.

Say that this is exactly what the user instance is. I believe that resets us back to the use case itself.

[CyrusNajmabadi]

Say that this is exactly what the user instance is. I believe that resets us back to the use case itself.

Once you have that, why do you need a special operator? You just use ..

We need a special operator for null as we throw otherwise. But since you don't have the problem here, why not just get the instance value back with the API on it that is legal to use?

[AndersKehlet]

Doesn't this generalize to monadic operations? Since we're getting tagged unions I'd rather just go all the way.

[Serdan]

If the goal is just safe chaining of operations you could presumably also hijack LINQ.

var result = from v1 in unityObject
             from v2 in someMethod(v1) 
             select someOtherMethod(v2);

public static class ObjectExtensions
{
    public static TResult? Select<TSource, TResult>(this TSource? self, Func<TSource, TResult?> selector) =>
        self == null ? default : selector(self);

    public static TResult? SelectMany<TSource1, TSource2, TResult>(
        this TSource1? self,
        Func<TSource1, TSource2?> selector,
        Func<TSource1, TSource2, TResult?> resultSelector)
    {
        if (self == null)
        {
            return default;
        }

        var temp = selector(self);
        if (temp == null)
        {
            return default;
        }

        return resultSelector(self, temp);
    }
}