State that the set of ValueTuple types provided is implementation-defined

[jskeet]

Part of #768.

@Nigel-Ecma I'm not sure this fully addresses your concern of "Do we need to say anything about how one implementation handles tuple values created by another with a different m?" from #664, but I couldn't think of a simple way of stating that. I'm hoping you'll agree that saying that the set of types available is implementation-defined implies that you shouldn't expect to be able to use code compiled for one implementation on another implementation, but other suggestions are welcome :)

[KalleOlaviNiemitalo]

Reading this made me worry about possible conflicts in overloaded methods, if one method takes an (int, int, int, int, int, int, int, char, char) parameter and another overload takes (int, int, int, int, int, int, int, (char, char)) -- does the compiler translate both of those to ValueTuple<int, int, int, int, int, int, int, ValueTuple<char, char>>? But no, the latter becomes ValueTuple<int, int, int, int, int, int, int, ValueTuple<ValueTuple<char, char>>> instead. Here, TRest is a ValueTuple<T1> with only one type argument, and does not correspond to any C# tuple type. The wording "a nested tuple value" is a bit misleading, then, as it could be taken to mean an instance of a tuple type.

Perhaps "shall be a set of generic struct types capable of expressing tuple types of any arity greater than one" should also be changed to require ValueTuple<T1>, at least in those implementations that translate large-arity tuple types to System.ValueTuple<..., TRest>. If the implementation does generate a dedicated generic type for tuple types of each arity, instead of using TRest, then I suppose it need not support ValueTuple<T1>, because:

• The non-generic struct ValueTuple and its public static ValueTuple<T1> Create\<T1>(T1 item1) method is not part of Annex C Standard library.
• struct ValueTuple<T1> is part of Annex C Standard library, but its omission can be excused because "The precise set of System.ValueTuple<...> types provided is implementation-defined."

[Nigel-Ecma]

@KalleOlaviNiemitalo – I see your point but rather than trying to improve the wording I would suggest a different tack.

The C# Standard does not specify a “wire format” for interoperability of binary data, or how arrays should be stored, and a myriad of other things. Why is it specifying how a tuple should be stored? Why even mention ValueTuple? Are these not implementation details of the kind the Standard doesn’t usually cover?

Rather than add a sentence to the end of the paragraph, and the following note, why not delete ”This syntax is shorthand for … arity greater than one” instead?

[Nigel-Ecma]

If the translation from language-level tuples to structures built from ValueTuple is to be included, as implementation-defined or not, then the issue raise by @KalleOlaviNiemitalo needs to be addressed.

Now while I might like the idea in my response of classing the whole translation as an implementation issue, and not discussing it past something like “the underlying storage structure for tuples, like for arrays, is an implementation issue”, I expect that is not going to happen. That leaves addressing the 1 “tuples” to address, somehow…

[jskeet]

Actions from meeting 2023-07-12:

• @Nigel-Ecma to write a suggested paragraph that removes all reference to System.ValueTuple
• @jskeet to write a suggested paragraph that addresses the womple concern

[jskeet]

Alternative suggestion from @gafter: we take the standard in the other direction, specifying exactly what set of types we have.

[jskeet]

... and now we're considering whether womples are actually tuple types despite not having syntax.

New proposal:

• Specify the complete set of ValueTuple<...> types
• Specify that womples exist, but cannot be written using tuple type or tuple literal syntax (do this bit properly!)

Thing to check: whether == is handled "appropriately" (in the compiler) by ValueTuple<T> and ValueTuple. If it is, we should describe these as tuple types.

[jskeet]

Nope, it looks like ValueTuple and ValueTuple<T> are not tuple types in terms of ==:

ValueTuple<int> x = new ValueTuple<int>(5);
ValueTuple<int> y = new ValueTuple<int>(5);
// Operator '==' cannot be applied to operands of type 'ValueTuple<int>' and 'ValueTuple<int>'
Console.WriteLine(x == y);

ValueTuple v1 = new ValueTuple();
ValueTuple v2 = new ValueTuple();
// Operator '==' cannot be applied to operands of type 'ValueTuple' and 'ValueTuple'
Console.WriteLine(v1 == v2);

(We are somewhat surprised by that.)

[jskeet]

@jskeet to try to create a new PR that specifies all System.ValueTuple types, and rewrites the representation to only go one way (to System.ValueTuple without coming back out in terms of "tuples types" for the continuation part).

(This will be in a separate PR.)

[jskeet]

Closing in favor of #876.