Discussion: Implicit Conversion from Tuples to Any Type

[HaloFour]

I was reading through the comments on #676 and it made me wonder what benefits there might be in allowing tuples to be convertible to other arbitrary types if after exhausting all other options the compiler could match the tuple to a constructor of that type. Something like this:

public class Person {
    public string Name { get; }
    public string City { get; }

    public Person(string name, string city) {
        Name = name;
        City = city;
    }
}

Person person = ("Bill", "Redmond");
// equivalent to
Person person = new Person("Bill", "Redmond");

The conversion would only be considered when:

1. The target type of the expression is known
2. There are no existing conversion operators defined between that tuple and the target type

Open questions:

1. Should tuple element names be taken into consideration?
2. Should the compiler consider constructors with optional parameters if the tuple doesn't have enough elements to exactly match any of the other constructors?

I want to say that there was also a proposal on the Roslyn repo for something similar.

[jjvanzon]

All the other constructs are having an existential crisis because of these tuples.

[jnm2]

I vote down only because I prefer the new keyword to be required and we have a proposal that will make Person person = new ("Bill", "Redmond") possible.

[wengys]

I vote down as this conversion seems conflict with var

var person = ("Bill", "Redmond"); // ???????

I would prefre som spreading operator, like

var person = new Person( ...personTuple );

[lachbaer]

I found this interesting when there was an implicit fan out of the itemes of a value tuple to the arguments of a constructor.

public Person(string name, string city) { ... }

var personTuple = ("Bill", "Redmond");
Person person = new Person(personTuple);

In case of an existing constructor with a corresponding ValueTuple as parameter, that one takes precedence of course.

[TessenR]

How should the feature interact with optional parameters?

class Program
{
  static void Main()
  {
    M(("", "")); // do you expect overload resolution to disambiguate it somehow?
  }  
  static void M(Person1 p) {}
  static void M(Person2 p) {}
}

class Person1 { public Person1(string s1, string s2) {} }
class Person2 { public Person2(string s1, string s2, string s3 = default) {} }

How should it interact with type inference?
Currently the following program compiles as Person does have an implicit conversion to a tuple (string, string) but not vice versa.

class Person
{
  static void Main()
  {
    M(new Person(), ("", ""));
    M(() => 
    {
      if (new Random().Next() > 1)
        return new Person();
      return ("", "");
    });
  }

  static void M<T>(T t1, T t2) {}
  static void M<T>(Func<T> f) {}
  
  public Person(string s1, string s2) { }
  public static implicit operator (string s1, string s2) (Person p) => ("", "");
}

Under the original proposal both calls will become ambiguous as both types are implicitly convertible to each other. That's a breaking change.

Also the code will become brittle as the program above will rely on the presence of the constructor with two string arguments. Adding/removing the constructor or changing its signature will either make the code above behave differently or will make it ambiguous.

[HaloFour]

@wengys

It doesn't conflict with var. It simply performs no conversion in that case and the result would be a tuple. The conversion would only apply in the case that the target type isn't a tuple.

@TessenR

The compiler already has rules for dealing with overloads and optional parameters. I'd expect that the same rules would be followed.

And, as stated (not so explicitly) above, this conversion consideration would be a last ditch effort by the compiler. If there's an existing way to convert the tuple to the type that would be used instead. If a different overload would be considered due to the lack of a conversion, that overload would be invoked instead. The only time that this conversion would be considered is if otherwise the code would fail to compile. I do realize that this opens up other potential cans of worms, that's why this is a discussion.

Also the code will become brittle as the program above will rely on the presence of the constructor with two string arguments. Adding/removing the constructor or changing its signature will either make the code above behave differently or will make it ambiguous.

Changing a constructor signature is already a breaking change and ambiguity is already a consequence of that.

[melanchall]

What if constructor throws an exception? I think it is a big pitfall with this idea. Implicit cast should never throw an exception.

[GeirGrusom]

How about a binary operator for it? I wrote a parser some time ago with this functionality which used ! as a binary operator, which is otherwise only a unary operator, and it would look something like this:

var arguments = ("Bill", "Redmond");
var person = new Person!arguments;

[ufcpp]

Tuple splatting?