Proposal: An interface which implements true, false, &, |, operators in base interfaces should be allowed to use short-circuiting && and || operators

[Charlieface]

Summary of proposal

It should be allowed that an interface IDerived : IBase1, IBase2, which implements true, false, &, |, operators via any base interfaces IBase1 IBase2, should be allowed to use short-circuiting operators && and ||, despite the fact the combining operators are defined in separate base interfaces.

This allows the various operators to be defined in separate interfaces, something which is very common with other operators in System.Numerics. It's a blocking issue on implementing ITruthOperators, as noted in this issue on dotnet/runtime. It's very surprising that this doesn't work at the moment, as it doesn't follow the normal overload resolution for operators in the spec.

Note that this is not allowing | or & to short-circuit. It's merely widening the scope of overload resolution so that || and && work in more cases.

---

Explanation

Some of the user-defined operators you can define in C# include:

bool operator true(T value);
bool operator false(T value);
T operator &(T left, T right);
T operator |(T left, T right);

The C# spec (12.14.3) then specifically allows for short-circuiting operators && and || to be used.

When the operands of && or || are of types that declare an applicable user-defined operator & or operator |, both of the following shall be true, where T is the type in which the selected operator is declared:

• The return type and the type of each parameter of the selected operator shall be T. In other words, the operator shall compute the logical AND or the logical OR of two operands of type T, and shall return a result of type T.
• T shall contain declarations of operator true and operator false.
  A binding-time error occurs if either of these requirements is not satisfied. Otherwise, the && or || operation is evaluated by combining the user-defined operator true or operator false with the selected user-defined operator:
  etc

In the case of interfaces, these operators can be defined as static abstract, which means you can use that interface as a generic type argument, and the operators then work based on the actual reified type at runtime.

---

However, it does not allow for the false operator to be in a different interface than the &, or the true to be in a different interface than the ||, even if one interface inherits the other, or the type parameter is declared inheriting both types.

For example, the following code is taken from the proposal for dotnet/runtime

public interface ITruthOperators<TSelf>
    where TSelf : ITruthOperators<TSelf>
{
    static abstract bool operator true(TSelf value);

    static abstract bool operator false(TSelf value);
}

The following code generates a compiler error:

public T IsTrue<T>(T left, T right) where T : ITruthOperators<T>, IBitwiseOperators<T, T, T>
{
    return left && right;
}

It would only be allowed if all operators were declared together, which is quite awkward for that linked proposal, because IBitwiseOperators is already defined in the CLR.

public interface ITruthOperators<TSelf>
    where TSelf : ITruthOperators<TSelf>
{
    static abstract bool operator true(TSelf value);

    static abstract bool operator false(TSelf value);

    static abstract TSelf operator &(TSelf left, TSelf right);

    static abstract TSelf operator |(TSelf left, TSelf right);
}

---

In a closed bug report on this in dotnet/roslyn, @jaredpar and @AlekseyTs state this is intentional, because the above spec states:

where T is the type in which the selected operator is declared
..snip..

• T shall contain declarations of operator true and operator false.

and that is expected to be the interface itself, not any of its base types.

Proposal

I propose that the spec is relaxed as follows: (change in bold)

• The return type and the type of each parameter of the selected operator shall be T. In other words, the operator shall compute the logical AND or the logical OR of two operands of type T, and shall return a result of type T.
• T or any of its base types shall contain declarations of operator true and operator false. Unary operator overload resolution (12.4.4) shall be used to find the operator, and shall be calculated separately from the resolution of & or |.

I can see no reason why this should be an issue, but there may be some corner cases involving nullable types or similar.

[HaloFour]

EDIT: Oops, misread the proposal. I do see that it is intended to allow && and || operators to be used on these types and short-circuit, not to add short-circuiting to the & and | operators themselves.

I disagree with allowing |/& to short-circuit. It's been in the definition of those operators since the inception of C# that ||/&& always short-circuit and |/& never short-circuit. This proposal would be a drastic change and make it impossible to tell from consumption whether or not an expression will short circuit.

Personally, I would much rather loosen the restrictions around the ||/&& operators to allow them to be overloadable.

[Charlieface]

@HaloFour Sorry I think you're misunderstanding. The intention is that || and && short-circuit as has always been allowed, by using & and |, false and true combined to create a short-circuit. The proposal is merely to allow them to be defined in different base types.

Maybe I wasn't clear, perhaps I should modify the title etc

[tannergooding]

The general intent of the proposal here is that the following should be legal:

public interface IBoolean<TSelf> : IBitwiseOperators<TSelf, TSelf, TSelf>
    where TSelf : IBoolean<TSelf>
{
    static abstract bool operator true(TSelf value);
    static abstract bool operator false(TSelf value);
}

Which would then allow a user-defined type such as the following:

public readonly struct BOOL : IBoolean<BOOL> {
    private readonly int _value;
    
    public BOOL(int value)
    {
        _value = value;
    }
    
    public static bool operator true(BOOL value) => value._value != 0;
    
    public static bool operator false(BOOL value) => value._value == 0;
    
    public static BOOL operator &(BOOL left, BOOL right) => new BOOL(left._value & right._value);
    
    public static BOOL operator |(BOOL left, BOOL right) => new BOOL(left._value & right._value);
    
    public static BOOL operator ^(BOOL left, BOOL right) => new BOOL(left._value & right._value);
    
    public static BOOL operator ~(BOOL value) => new BOOL(~value._value);
}

Which would then allow the following code to light-up:

public static void M<T>(T x, T y)
        where T : IBoolean<T>
{
    // error CS0217: In order to be applicable as a short circuit operator a user-defined logical operator ('IBitwiseOperators<T, T, T>.operator &(T, T)') must have the same return type and parameter types
    if (x && y)
    {
        Console.WriteLine("A");
    }
    else   
    {
        Console.WriteLine("B");
    }
}

The code already works as expected if you directly take BOOL and don't use generics:

public static void M(BOOL x, BOOL y)
{
    if (x && y)
    {
        Console.WriteLine("A");
    }
    else   
    {
        Console.WriteLine("B");
    }
}

---

I don't think that this should necessarily be fully relaxed. That is, I don't think you should allow two distinct interface hierarchies to define such functionality and allow short-circuiting.

However, I believe it can be allowed from a single inheritance hierarchy like the above, where it can be "more clear" about the user intent. This would allow such functionality to be provided without needing to duplicate how the base bitwise operators are defined.

[HaloFour]

Oh I see, I did miss the part where the combination of operators would then effectively "overload" the && and || operators which would short-circuit, and continued use of the & and | operators would not short-circuit. I withdraw my disagreement. :)

Honestly feels like a bit of a miss that it doesn't already work with generics.