Permit type inference based on default parameters

[alx9r]

tl;dr;

public static void Foo<A>(A a)    {}
public static void Bar<A>(A a=42) {} // ERROR: CS1750

static void usage2() {
    Foo(42); // this is fine
    Bar();   // this should be equivalent and work too
}

---

The motivation for this seems close to #1348 and #1349. To my reading permitting this might be moot if those are implemented. It's probably too early to say; there doesn't seem to be a spec for that feature yet.

My stackoverflow question about this has some exploration of where I thought the C# spec applies.

What I am trying to do here

In the example below I am trying to accomplish default type deduction by specifying default parameters in the declaration of a generic method.

Why I am trying to do this

I have some objects that have on the order of 10 generic parameters. The object is a projection of a well-understood and -structured domain into C#. Strongly-typing the parameters prevents use at compile time of those objects in ways that make no sense in the domain.

Most of the parameters have default values that are natural in the domain.
The natural way to specify such an object is to provide an arbitrary subset of the parameters when creating the objects. Default parameters works very well in such a situation because doing so dramatically reduces the number of overloads necessary to support defaults.

I'd like to be able to use default parameters with generic methods to avoid the many overloads that would otherwise be required to handle the omission of an arbitrary combination of parameters. I'd like to be able to do that when those parameters have generic types.

Why I think this should work

My naïve interpretation of the 5.0 spec is that type inference based on default parameters isn't prohibited.

From the example below it seems like the following two calls

Foo(42);
Bar();

should be equivalent.

Example

public class T {}
public class T0  : T {}
public class T1  : T {}
// T2{} .. T9{}
public class T10 : T {}
public struct S<T> {}
public class X {} // X is a complex object strongly-typed with T1..T10
public static class C {
    public static X Factory<A,B/*,C..J*/>(
        S<T0> s = new S<T0>(), // this is fine
        S<A>  a = new S<T0>(), // ERROR: no standard conversions to type...
        S<B>  b = new S<T0>()  // ...'S<A>' [TypeInference]csharp(CS1750)
        //S<C> c,
        //...
        //S<J> j
    )
    where A : T
    where B : T
    =>throw new System.NotImplementedException();

    static void usage1() {
        /* I'd like to be able to omit an arbitrary portion
           of the factory arguments and have type inference use
           the default values.*/
        Factory(b : new S<T1>());
    }

    // simplified example
    public static void Foo<A>(A a)    {}
    public static void Bar<A>(A a=42) {} // ERROR: CS1750

    static void usage2() {
        Foo(42); // this is fine
    }
}

Expected result:

When public static void Bar<A>(A a=42) {} is called using the default Bar(42), Bar<int>(int a) is inferred.

Actual result:

public static void Bar<A>(A a=42) {} results in

(parameter) A a = 42
A value of type 'int' cannot be used as a default parameter because there are no standard conversions to type 'A' [TypeInference]csharp(CS1750)

[YairHalberstadt]

I think I understand the proposal, but I can't think off the top of my head of any time I would have used it. I think it would be help evaluate your proposal if you explained in more detail exactly what your use case is.

[alx9r]

@YairHalberstadt Thank you for the reply. I'll try to think of a more common example; the domain where this arose is fairly esoteric.

[alrz]

If I understand it correctly, the workaround you have today is this:

public static void Bar<A>(A a) {}
public static void Bar(int a = 42) => Bar<int>(a);

The overloads could be generated by a source generator, so you could just provide a partial declaration,

public static void Bar<A>(A a) {}
public static partial void Bar(int a = 42);

Since CLR can't represent A a = 42 default, even as a language feature, the compiler will need to use the same technique.

[alx9r]

If I understand it correctly, the workaround you have today is this:

public static void Bar<A>(A a) {}
public static void Bar(int a = 42) => Bar<int>(a);

In principle, yes. However, this workaround is impractical because of the combinatorics of the overloads required to cover the omission of all combinations of arguments. My domain has on the order of 10 arguments to generic factory methods, so the full complement of overloads would be on the order of 100:

100 or so overloads

static void Product<A,B,C,D,E,F,G,H,I,J>(
    A a,
    B b,
    C c,
    D d,
    E e,
    F f,
    G g,
    H h,
    I i,
    J j
) {}

static void Product_NoA<B,C,D,E,F,G,H,I,J>(
    B b,
    C c,
    D d,
    E e,
    F f,
    G g,
    H h,
    I i,
    J j
) => Product("a",b,c,d,e,f,g,h,i,j);

static void Product_NoB<A,C,D,E,F,G,H,I,J>(
    A a,
    C c,
    D d,
    E e,
    F f,
    G g,
    H h,
    I i,
    J j
) => Product(a,"b",c,d,e,f,g,h,i,j);

//... 7 more overloads ...

static void Product_NoC<A,B,D,E,F,G,H,I,J>(
    A a,
    B b,
    D d,
    E e,
    F f,
    G g,
    H h,
    I i,
    J j
) => Product(a,b,"c",d,e,f,g,h,i,j);

// ... approximately 90 more overloads

static void Product_OnlyJ<J>(J j)
=> Product("a","b","c","d","e","f","g","h","i",j);

As I understand the history of C#, avoiding this sort of combinatoric explosion was part of the motivation for the combination of named arguments and default parameters.

[HaloFour]

My understanding is that default and named parameters were added almost specifically to map the existing Office interop APIs cleanly into C#, and the C# team had to kind of be forced into doing it when the Office team couldn't come up with a suitable shim API.

Your case seems pretty nasty, but it's also very unlikely to happen more than once.

[alx9r]

@HaloFour

IMO, optional parameters are not the correct way to convey these kinds of methods, non-generic overloads are.

I agree with this for small numbers of parameters. However, the number of overloads grows with n^2 where n is the number of parameters.

[alx9r]

My understanding is that default and named parameters were added almost specifically to map the existing Office interop APIs cleanly into C#, and the C# team had to kind of be forced into doing it when the Office team couldn't come up with a suitable shim API.

Interesting. And all this time I thought I was benefitting from reduced number of overloads because of deliberate design choices to do so.

[HaloFour]

However, the number of overloads grows with n^2 where n is the number of parameters.

Source generators can generate those members for you. It's not ideal, and indeed painful, but it would be substantially more painful to implement this within the compiler as a language feature, and would need to have a demonstrable benefit in more general-purpose use cases.