static (string Name, int Age) GetUser() => ("Mina", 26);

var user = GetUser();
Console.WriteLine(user.Name);

var (name, age) = GetUser();
(_, int onlyAge) = GetUser();

선언, 반환, 구조 분해

(int X, int Y) point = (3, 4);
(string, int) unnamed = ("Mina", 26);

static (bool Success, string? Error) Validate(string email)
{
    return email.Contains('@')
        ? (true, null)
        : (false, "Missing @");
}

var (success, error) = Validate("mina@example.com");

tuple element name은 선언·대입에서 보존되거나 추론될 수 있지만, tuple의 shape는 위치와 element type이 중심입니다. 같은 위치·type의 tuple을 다른 이름으로 바꿨다고 distinct runtime data type이 생기지 않습니다. name은 caller의 이해를 돕지만 serialized schema나 long-lived compatibility contract를 name만으로 보장하지 않습니다.

public sealed class Point(double x, double y)
{
    public double X { get; } = x;
    public double Y { get; } = y;

    public void Deconstruct(out double x, out double y) => (x, y) = (X, Y);
}

var (x, y) = new Point(3, 4);

deconstruction은 out parameter pattern을 찾습니다. 필요한 값만 받지 않을 때 _ discard를 쓰고, 별도의 _ local variable과 의미가 충돌하지 않도록 짧은 deconstruction scope에 둡니다.

Tuple, record, class 선택

public API가 tuple을 절대 쓸 수 없다는 뜻은 아닙니다. 작은 결과가 명확하고 versioning 비용이 낮으면 유용합니다. 다만 element가 늘거나 의미·validation·serialization 요구가 커지는 순간 named record/class가 caller와 library의 변경을 더 명확히 관리합니다.

tuple은 값 타입이라는 이유만으로 stack allocation을 보장하지 않습니다. 값 복사와 boxing conversion 가능성이 type 계약이고, 실제 allocation은 usage와 runtime implementation에 따라 달라집니다.

자주 틀리는 부분