Going further with discards "_"

[polijp]

Discards have been introduced since a few C# versions. They prevent for naming a variable that won't be used later and may allow some compiler optimizations.

It would be very efficient if we can know that a discard is used.

Let's take, for instance, a method that computes the SVD decomposition of a matrix. It generally returns 3 matrices S, W and Vt. In some occasion, for instance to compute the rank of a matrix, only the W matrix is needed. Such a method may look like this:

void SVDDecomposition(double[,] a, out double[,] s, out double[] w, out double[,] vt) { ... }

and the call in the GetRank() method:

SVDDecomposition(a, out _, out var w, out _);

Basically, this call will compute the three matrices and two of them won't be used.

I'd like my SVDDecomposition to know that I don't need the matrices s and vt, without adding arguments myself.

For instance, with the use of a keyword inside the function:

void SVDDecomposition(double[,] a, out double[,]? s, out double[]? w, out double[,]? vt) 
{
    if (needed(s)) Compute s;
    if (needed(w)) Compute w;
    ...
}

The compiler will generate the code that gives the relevant value to needed(...), maybe by adding boolean parameters to the signature of the method.
Instead of needed, we could reuse the required keyword, not to extend too much the list of C# keywords:

void SVDDecomposition(double[,] a, out double[,]? s, out double[]? w, out double[,]? vt) 
{
    if (required(s)) Compute s;
    if (required(w)) Compute w;
    ...
}

For nullables, we could have a rule or an attribute like [NotNullWhenRequired].

The same should work for returning tuples:

(double[,]? s, double[]? w, double[,]? vt) SVDDecomposition(double[,] a) 
{
    if (required(s)) Compute s;
    if (required(w)) Compute w;
    ...
}

[TahirAhmadov]

Why not add overloads, and move common code to internal helper methods?

[polijp]

Presently it’s what I do. First I produce myself a code that could be automated. Second, there’s no semantic link in the discard and the value of the Boolean.

So my suggestion consists in:

• reducing the code written manually
• Avoiding having too much parameters to write (decreasing the readability of the written code)
• Bringing consistency between these parameters and the discard symbol
• Bringing convention to the naming of such parameter
• Giving more reasons to use discard symbol.

It’s not a big deal to make the compiler produce this code properly at compile time. But in my opinion it will result in a cleaner code, optimal scenarios for scientific computation, while even not overloading the list of keywords :). A lot of my methods would benefit from this.

[huoyaoyuan]

You are messing up with the nullability level in the example. You were requesting Class**? but specifying Class*?*.

In current C#, it can be described with Unsafe.NullRef:

void Method(ref Result result)
{
    if (!Unsafe.IsNullRef(ref result)) Compute result;
}

Method(ref Unsafe.NullRef(result));

or with out:

void Method(out Result result)
{
    Unsafe.SkipInit(out result);
    if (!Unsafe.IsNullRef(ref result)) Compute result;
}

Method(out Unsafe.NullRef(result));

[polijp]

I’m not sure to get your point. Actually it’s like in the Try… scenarios (eg TryGetValue in Dictionary) when you use the NotNullWhenAttribute.
In my case, It’s just to tell the compiler that the return value of the out parameter is null if and only if there is a discard symbol matching with this parameter.

My suggestion may only apply on out parameters and on returning tuples.

[huoyaoyuan]

the return value of the out parameter is null if and only if there is a discard symbol matching with this parameter.

This is the misunderstanding point. The return value can't be affected by caller. In other words, the callee can never know how the caller accepts the out value. Instead, the (address of) variable accepting the return value needs to be specified as nullable in the use case.

[polijp]

This is all the point of my suggestion. Having a mechanism that tells the callee that the caller used a discard. Presently, what I write is that: ``` void SVDDecomposition(double[,] a, bool sneeded, bool wneeded, bool  vtneeded, out double[,]? s, out double[]? w, out double[,]? vt) … ``` There is a semantic and intrinsic matching between sneeded and the use of a discard in the call for out parameter s, and same from wneeded and w, vtneeded and vt. I would appreciate if instead of writing the Boolean parameters and paying attention to set them to false when discard is used the compiler would take on charge itself. It’s just cleaner, time saving, avoiding misused parameters, avoiding writing doc on these parameters, etc

[huoyaoyuan]

This proposed approach won't work totally because:

• Discard are currently undistinguishable. It's just a syntax sugar of creating a temporary variable and throw away.
• There is no non-breaking way to allow discards becoming distinguishable. Unsafe.NullRef is not commonly expected.
• The proposed syntax conflicts with usual nullable reference type usage.

[huoyaoyuan]

To make it ever possible, a new variation of out modifier must be involved, and it won't be compatible with existing out semantics.

[polijp]

We can see that as [CallerMemberName] that gives a value to a parameter. Roslyn is already able to recognize the _ as a discard symbol (see IDiscardSymbol for instance). Found in Microsoft C# documentation : “a discard communicates intent to the compiler and others that read your code”. Since my suggestion is just at compile time, it may be possible, don’t you think ?

[huoyaoyuan]

Like CallerMemberName which needs an additional parameter to accept, it also needs additional parameter/contract (that is Unsafe.NullRef) to accept the "whether discard or not" information, which doesn't comply with existing out mechanism. No matter what mechanism is used, it has to be breaking.

[HaloFour]

I don't see much happening here unless the team changes their mind on exposing ref null more directly. Silently changing the signature to pass bool flags seems even less likely, even through an optional CallerDiscardParameterAttribute or the like.

[polijp]

I think you answer to my questions. It’s not possible to smile you add parameters to a méthode.
Not sure having attributes will be as practical.

[BlinD-HuNTeR]

Sir, I guess I have a workaround for you, that already works as of today:

I agree with everyone else on the matter that "making discards distinguishable" is very complicated, you can't simply make the compiler pass Unsafe.NullRef in the place of a discard, as it would break pretty much everything.

But, you can exploit [CallerArgumentExpression] to detect if the caller has used a discard. If they did, the value of the "Caller Argument Expression" will be exactly equal to "_".

I'm not sure if there might also be spaces around the "_", but you can use Trim, if you want to be safe. Plus, it's not like your code will break if it fails to detect the discard and populates the out variable. So I guess you have nothing to lose.

[colejohnson66]

It doesn't always work. If I do out int _ instead of out _, the argument expression is int _:

https://sharplab.io/#v2:CYLg1APgAgDABFAjAOgEoFcB2AXAlgWwFNkBhAe3wAdcAbQgJwGUGA3XAY0IGcBuAWABQgqAGYEAJjgkaAQy5dBAb0FxVCMVAAscALKFsACzLAAFAEoVa5QLW24AFW7YTZdNjgB9M/xt3VjrmdXd1wcT29LVQBfSLhY0QREADYEbQCgtzhQ9xl6AHMAGjgAbRIZGjp6AEF89CIcAFEAD0p6bi5cMkwTTBkiMgAzE1y8szMAXUSYAH44Qhb6OABeOEx0CotfVWs/VQBVTC4ZAeJGAGtcSgBJTFwMnPyIrbgYgSigA

using System.Runtime.CompilerServices;

public class Class
{
    public void Method()
    {
        Test(out _);
        Test(out int _);
    }
    
    public static void Test(out int arg, [CallerArgumentExpression(nameof(arg))] string? expr = null)
    {
        Unsafe.SkipInit(out arg);
    }
}

Sure, this can all be detected, but then you'd need the LibraryImport generator and CsWin32 to be aware of this hack.

Plus, it's not like your code will break if it fails to detect the discard and populates the out variable.

Not true. There's a lot of P/Invoked code (C libraries) that do different things if the out parameter is NULL or not. So populating the out variable can actually cause the library to do something entirely different. That's why there are proposals for out null or ref null.

[polijp]

Ok for closing