Improve resolution of 'new expressions' for params

[kofifus]

Consider:

class MyList<T> {
  public MyList(params T[] ts) { /* add all items to internal list */ }
}

record Employee(string Name, int Age);

var l1 = new MyList<Employee>(new Employee("John", 30));   // ok

var l2 = new MyList<Employee>(new("John", 30));  // error CS8752: The type 'Program.Employee[]' may not be used as the target type of new()

var l3 = new MyList<Employee>(new("John", 30), new("Eric", 30)) // ok;

If my understanding is correct, the reason for the error in l2 is that according to the standard:

A target_typed_new expression does not have a type. However, there is a new object creation conversion that is an implicit conversion from expression, that exists from a target_typed_new to every type.

However in this case I believe the compiler can be improved to detect that the new expression needs to be a new Employee and not Employee[]

Thanks

[svick]

Somewhat similar suggestion, but for pointers instead of arrays: #4895.

[RikkiGibson]

I think overload resolution considers whether the method is applicable in "normal" or "expanded" form when deciding what the best overload is. I think the spec/implementation change may actually be essentially an overload resolution change, i.e. the use of target typed new indicates that the argument is not an array type.

[CyrusNajmabadi]

Yeah. I'm a little bit surprised this didn't just fall out @RikkiGibson . There should be two candidates here MyList(Employee[] ts) (the array form without hte params) and MyList(Employee) (the expanded form to this number of arguments). The first should fail as new(...) can't be used to target type an array. The second form should succeed.

Are we sure this isn't actually a bug in the compiler?

[alrz]

The first should fail

No. "new() can convert to any type" i.e. it has no significance in the overload resolution, but the conversion itself may still fail, and since the normal form takes precedence, we end up with this error.

[CyrusNajmabadi]

i see. yes. we'd need to revise the rules here.

[sab39]

Would the outcome change if MyList<T> contained a second constructor overload?

  public MyList(T t) : this(new[] { t }) { }

[KathleenDollard]

I wanted to ping this issue because when you encounter this as a use it is quite unexpected. This will occur in many designs and seems worth fixing.