How do out parameters work in C#, and when should you use them? Explain definite assignment, out var and discards, the Try pattern, how out relates to ref under the hood, why async methods and iterators cannot have out parameters, nullable annotations for Try methods, and when a tuple or result type is a better choice.

How I would answer this in an interview

An out parameter lets a method return an extra value through a reference to the caller's variable. The callee must assign it before returning, and the caller's variable is definitely assigned afterwards. Its main legitimate use today is the Try pattern (bool TryParse(string s, out int value)). I'd cover definite assignment, out var and discards, the Try pattern, how out relates to ref, why async/iterators can't have them, nullable annotations, and when tuples or result types are better.

1. Definite assignment

public static bool TryParsePostcode(string? input, out int postcode)
{
    postcode = 0;                                   // must assign on every non-throwing path (CS0177)
    if (input is not { Length: 4 }) return false;
    return int.TryParse(input, NumberStyles.None, CultureInfo.InvariantCulture, out postcode);
}

• Callee: the out parameter starts unassigned; reading it before assignment is CS0269; every return path must assign it.
• Caller: doesn't need to initialise the variable; it's definitely assigned after the call.

2. out var and discards

if (int.TryParse(text, out var quantity)) Use(quantity);   // declare inline (C# 7)
if (dict.TryGetValue(key, out _)) { ... }                  // discard when you don't need the value
if (DateOnly.TryParse(s, out DateOnly date)) { ... }       // explicit type

The variable's scope is the enclosing statement/block (it "leaks" into the containing scope for if statements), which allows if (!int.TryParse(s, out var n)) return; Use(n);.

3. The Try pattern

The BCL's convention for operations where failure is expected and common:

• bool TryXxx(input, out T result): returns true + result on success, false (with default result) on failure — no exceptions.
• Paired with a throwing Xxx(input) for callers who treat failure as exceptional.
• Examples: int.TryParse, Dictionary.TryGetValue, ConcurrentQueue.TryDequeue, Enum.TryParse, IPAddress.TryParse, TryFormat(Span<char>, out int written).

This avoids exceptions in hot paths (parsing user input) while keeping the API simple.

4. How out relates to ref under the hood

In IL, out and ref are the same: a managed pointer (T&) to the caller's storage. out adds [Out] metadata and compiler-enforced definite-assignment rules. Consequences:

• You can't overload M(out int) and M(ref int) — same signature at the CLR level.
• The callee can technically read through the pointer (the CLR doesn't stop it), but C# forbids reading before assigning.
• Passing a field or array element by out lets the callee write directly into it.

5. Why async methods and iterators can't have out (or ref/in) parameters

Async methods and iterators are compiled into state machines whose locals are hoisted into heap objects so they survive across await/yield. An out parameter is a managed pointer that may point to the caller's stack frame; storing it in a heap object would allow it to outlive that frame — a dangling reference. So C# forbids it (CS1988). Async "Try" APIs instead return tuples or result types: Task<(bool Found, Order? Order)>, ValueTask<Order?>.

6. Nullable annotations for Try methods

public bool TryGetCustomer(int id, [NotNullWhen(true)] out Customer? customer) { ... }
public bool TryGetValue(TKey key, [MaybeNullWhen(false)] out TValue value) { ... }   // generic: default on false

if (repo.TryGetCustomer(id, out var c)) Console.WriteLine(c.Name);   // no warning, no '!'

• [NotNullWhen(true)] on a nullable out reference: non-null when the method returns true.
• [MaybeNullWhen(false)] on a generic out T: may be default when returning false.
• Without them, callers get nullable warnings and start sprinkling !.

7. When a tuple or result type is better

• Multiple return values that aren't the Try pattern — out parameters for several outputs are awkward; return a tuple (private) or record (public).
• Async methods — out isn't allowed.
• Failures with reasons (not just true/false) — a result type (Result<T, Error>) or discriminated records carry the error.
• Fluent/LINQ code — out doesn't compose in expressions; tuples do.
• Public APIs that may evolve — adding another output to a record is easier than adding an out parameter.

I keep out for: Try patterns, low-level performance APIs (TryFormat(..., out int charsWritten)), and interop.

8. A production example

An API's ValidateOrder(Order o, out string error, out int errorCode, out bool isWarning) was called from new async code, forcing awkward wrappers. We replaced it with ValidationResult Validate(Order o) (a record with a list of errors and severity), which worked naturally in async handlers and in ASP.NET Core's ValidationProblem mapping. We kept TryParseOrderNumber(string, [NotNullWhen(true)] out OrderNumber?) for the hot parsing path.