[Proposal]: Proposal for Allowing Single-Element Tuples in Type Definitions

[Dogwei]

Dear CSharpLang Community,

I would like to propose the allowance of defining single-element tuples when defining types. I have identified two main benefits of this feature:

1. Semantic clarity in complex type definitions:

   Currently, the following code lacks semantic clarity, as we can only see 'key' and 'value'.

    using HotelRateCache = System.Collections.Generic.Dictionary<
        string,
        System.Collections.Generic.Dictionary<
            string,
            System.Collections.Generic.Dictionary<
                long,
                int
                >
            >
        >;

With single-element tuples, we can assign semantics as follows:

    using HotelRateCache = System.Collections.Generic.Dictionary<
        (string hotelId),
        (System.Collections.Generic.Dictionary<
            (string roomId),
            (System.Collections.Generic.Dictionary<
                (long longStay),
                (int hashCode)
                > longStayCache)
            > roomRateCache)
        >;

2. Semantic clarity in return values:

   Currently, the return value of the following code also lacks semantic clarity.

    public static int FromHotelKey(string hotelKey) => int.Parse(hotelKey);
    public static string ToHotelKey(int didaHotelId) => $"{didaHotelId}";

With single-element tuples, we can assign semantics as follows:

    public static (int didaHotelId) FromHotelKey(string hotelKey) => int.Parse(hotelKey);
    public static (string hotelKey) ToHotelKey(int didaHotelId) => $"{didaHotelId}";

If this proposal is accepted, I suggest allowing implicit conversion between ValueTuple<T> and T.

Of course, if there are other ways to solve these problems, that would be great as well.

Best regards

[ufcpp]

https://github.com/dotnet/csharplang/discussions/6636 https://github.com/dotnet/csharplang/issues/883

[333fred]

Closing as a duplicate of multiple other discussions. I would also remind you of the process spelled out in our README: new proposals need to start as discussions, not as issues, until a member of the LDM decides to champion it.