Generic returns

[IS4Code]

I am basing this discussion off of older proposals of mine (#3050, #3577). I feel the motivation behind the proposal and the solutions could be better discussed here.

Motivation

Suppose you have your own system of numeric types. It makes sense for all of them to implement a common interface, let's say this:

public interface INumber<T> where T : struct, INumber<T>
{
    T Add(T other);
    T Subtract(T other);
    T Divide(T other);
    T Multiply(T other);
}

These methods are all total - they can accept any argument (let's forget about division by zero for now).

How do you write a method that takes any number?

static T Calculate<T>(T a, T b) where T : struct, INumber<T>
{
    return a.Add(b).Divide(a.Subtract(b));
}

How do you write a method that returns any number? How do you use the result?

Solutions

There are situations when a generic object/value can be encountered that doesn't provide necessary operations that don't require knowing the actual/concrete type of it. At this point, there is no INumber that could be used in its stead.

How can this be solved?

• dynamic.
• Add INumber, implemented by INumber<T>.
• Externally - branch/specialize code based on the extracted type.
• Internally - the method can "return" the number in some way that preserves the type.

Let's skip dynamic and discuss the remaining options:

Base interface

Arguably the easiest option is to do something like this:

public interface INumber
{
    Type InnerType { get; }
    INumber Add(INumber other);
}

public interface INumber<T> : INumber where T : struct, INumber<T>
{
    T Add(T other);

    Type INumber.InnerType => typeof(T);
    INumber INumber.Add(INumber other) => other is T v ? Add(v) : throw new ArgumentException(nameof(other));
}

This works, but having to treat the number as boxed decreases performance. Also Add is not a total function anymore - you have to make sure you only add compatible number types.

This is something that is employed in .NET as well: All arrays derive from Array, which allows handling the values as object, and contains similar checks for input. The same is also true for List<T> implementing ICollection (with the same issues), but ICollection<T> does not implement ICollection, so you cannot be sure there if a cast succeeds.

Deciding on the type

You can return a number as object/ValueType, find the first INumber<T> it implements, extract the T, and either branch or specialize based on its value. This is explored in detail in #3050.

In this specific case, one would have:

object number = GetNumber();
if(number is INumber<new T> num where T : struct, INumber<T>) //or `number is new T where T : struct, INumber<T>`
{
    if(GetAnotherNumber() is T num2)
    {
        return num.Add(num2);
    }
}

This works well in general, but unless CLI provides instructions or tools for this kind of operation, it has to involve heavy reflection to work. I'd still like to be able to use this some day.

Consuming the type

This involves creating something akin to a "generic-Invoke delegate", a piece of code that itself has type parameters. Stemming from #3577, we could have:

public interface INumberConsumer<TResult>
{
    TResult Consume<T>(T val) where T : struct, INumber<T>;
}

public interface INumber
{
    TResult Accept<TResult>(INumberConsumer<TResult> consumer);
    // or alternatively
    TResult Accept<TResult, TConsumer>(TConsumer consumer) where TConsumer : INumberConsumer<TResult>;
}

This is the object-oriented way of solving this issue, but unless C# simplifies it, it is extremely cumbersome, since every operation must have an accompanying type. There are various degrees of assistance C# can provide, for example:

• Java-like anonymous types. With the powerful way closures are already created for anonymous methods, this can be employed to fix all the issues while providing support for all different sorts of cases:

  return GetNumber().Accept(new struct : INumberConsumer<INumber>
  {
      INumber INumberConsumer<INumber>.Consume<T>(T num) => GetAnotherNumber() is T num2 ? num.Add(num2) : null;
  });

• Recognizing that this is a functional interface, and implementing it accordingly:

  return GetNumber().Accept(delegate<T>(T arg) { return GetAnotherNumber() is T num2 ? num.Add(num2) : null; });

  delegate<T> here being the syntax for an anonymous method with a type parameter.
• Translating the pattern to a normal code flow:

  var num = await GetNumber();
  return GetAnotherNumber() is typeof(num) num2 ? num.Add(num2) : null;

I am going to pause at the last one and elaborate. While this syntax doesn't make it easy to obtain the returned type, I think it is more than an ugly hack. await was created for this purpose of flattening the code, so broadening its support in this sense isn't all that meaningless. There are lots of issues with this approach though, since await works based on a pattern that doesn't really allow generic results. And it also requires an awaiter, which is not optimal in this case.

The method itself should be its own simple awaiter:

TResult ProcessNumber<TResult, TConsumer>(TConsumer consumer) where TConsumer : INumberConsumer<TResult>;

C# could translate ProcessNumber() (without the consumer argument, or with another keyword like await) to constructing the necessary types and calling the method in the proper way. The result of the consumer would be anything that is returned after the call.

[HaloFour]

#339 and #1711

Handling numerics generically and with a zero-cost abstraction is one of the primary motivating use cases of shapes.

[IS4Code]

If we are talking about shapes as means of accepting types that don't speak our language (interfaces) or the language is not sufficient enough (static members), i.e. "realistic" shapes, then no, they won't help. I chose INumber since that is easy to describe, but I could have chosen IVector or IMatrix or any interface that can be applied to value types. It does not necessarily have to map to a .NET type. INumber could have had SquareRoot() and it could simply be implemented by a custom value type like Fraction, Complex or Real that conform to the interface. That is not important to the issue.

The point was to be able to return any value (primarily a value type) with minimal costs. If we are talking about "ideal" shapes, i.e. zero-cost treating of pattern-conforming values everywhere, then yes, they could help:

shape SAny { }

public static SAny GetValue(int type)
{
    switch(type)
    {
        case 0: return 1;
        case 1: return true;
        case 2: return "x";
        case 3: return new Complex(0, 1);
        default: return (object)null;
    }
}

var value = GetValue(0);
if(value is int i) ...

If value here is absolutely a value type in no boxed form and is converted to i with zero costs, then yes, that would indeed be awesome and would solve the issue.

Of course we could replace with SAny with something that does provide operations, but the point still stands - it has to keep its form and essence.

---

I try to follow up the now quite lengthy discussion about shapes, and pardon me the scepticism, but I feel some of the potential future uses would require miracles from both the compiler and the runtime. Shapes are already powerful in their "realistic" form, but there are now quite some issues that "could" be solved with shapes, but it's not pragmatic to wait for C# 12 for the solution, when it could be solved with something more concrete and realistic, like Java-like anonymous types here. Not saying it is the best solution, but neither is hitting a tiny nail with a sledgehammer.

[HaloFour]

If we are talking about "ideal" shapes, i.e. zero-cost treating of pattern-conforming values everywhere, then yes, they could help

Yes, that is a goal of shapes.

but it's not pragmatic to wait for C# 12 for the solution

The team isn't going to rush a solution, and they're certainly not going to consider a half-way solution for the sake of expediency.