C# Generic Out Parameter: Type Inference Explained

c# generic out parameter requires a clear understanding of the core syntax, runtime behavior, and practical implementation patterns demonstrated in the examples below.

The Core Constraint: Type Inference and out Parameters

When you write a generic method that has an out parameter, the C# compiler's type inference behaves differently than with regular parameters. Consider a method that tries to parse a string into a generic type:

public static bool TryParse<T>(string input, out T result)
{
    try
    {
        result = (T)Convert.ChangeType(input, typeof(T));
        return true;
    }
    catch
    {
        result = default;
        return false;
    }
}

Calling this method requires the type argument to be specified explicitly because the compiler cannot infer T from an out argument that has not yet been assigned:

if (TryParse<int>("42", out int value))
{
    Console.WriteLine(value);
}

The out int value declaration does not participate in type inference. The compiler needs TryParse<int> to know what T is before it can check assignment compatibility of the out argument. This differs from a method like T Parse<T>(string input), where the return type can drive inference in some call contexts.

Why out var Does Not Infer the Type Argument

A common mistake is to assume that out var lets the compiler figure out T:

// Does not compile: type argument cannot be inferred
if (TryParse("42", out var value))
{
}

The var keyword only tells the compiler to infer the type of the local variable from the type of the out parameter. But the type of the out parameter depends on T, which has not been resolved. This creates a circular dependency: the compiler would need to know T to type the variable, but it would need the variable's type to infer T. C# resolves this by requiring an explicit type argument in this situation.

The same rule applies to out parameters in generic interfaces and generic classes. If a generic interface declares a method with an out parameter, callers must supply the type argument explicitly unless it can be inferred from another parameter.

The Generic TryGetValue Pattern

The most common real-world use of a generic out parameter is the TryGetValue pattern used by Dictionary<TKey, TValue> and similar collection types:

public static bool TryGetValue<TKey, TValue>(
    IDictionary<TKey, TValue> dictionary,
    TKey key,
    out TValue value)
{
    if (dictionary.TryGetValue(key, out value))
    {
        return true;
    }
    value = default;
    return false;
}

Here the type arguments TKey and TValue are inferred from the dictionary and key parameters, not from the out parameter. The out TValue value parameter simply receives the inferred type. This is why the pattern works naturally with out var:

var config = new Dictionary<string, int>
{
    ["retries"] = 3
};

if (TryGetValue(config, "retries", out var retries))
{
    Console.WriteLine(retries);
}

The compiler infers TKey as string and TValue as int from the dictionary argument, so the out var local becomes int. The out parameter is a consumer of the inferred type, not a source of inference.

When You Must Specify Type Arguments Explicitly

If a generic method has an out parameter and no other parameter that can drive inference, you must write the type argument at the call site:

public static bool TryConvert<T>(string input, out T result)
{
    // ...
}

Every call must include the type argument:

if (TryConvert<double>("3.14", out double ratio))
{
    Console.WriteLine(ratio);
}

This is not a compiler limitation that will be removed in a future version. The C# language specification defines type inference as working only from arguments that already have a type. An out argument in a variable declaration (out int x) has a declared type, but it does not contribute to inference. An out var argument has no type until inference completes, so it cannot be a source of inference either.

Generic Constraints and out Parameters

Generic constraints apply normally to methods that use out parameters. A method that requires a parameterless constructor can enforce that with where T : new():

public static bool TryCreate<T>(out T instance) where T : new()
{
    instance = new T();
    return true;
}

Callers must specify T explicitly because there is no other parameter:

if (TryCreate<DateTime>(out var now))
{
    Console.WriteLine(now);
}

The default keyword is often used to initialize an out parameter when the operation fails. For a reference type, default is null; for a value type, it is the zero-initialized value. This matters when the caller reads the out value after a false return, because the parameter is guaranteed to be assigned by the method before it returns.

Runtime Behavior and Assignment Guarantees

The compiler enforces definite assignment for out parameters. Every code path through the method must assign the parameter before returning. This is a compile-time guarantee, not a runtime check. In a generic method, this interacts with default(T):

public static bool TryFind<T>(IEnumerable<T> items, Func<T, bool> predicate, out T found)
{
    foreach (var item in items)
    {
        if (predicate(item))
        {
            found = item;
            return true;
        }
    }
    found = default;
    return false;
}

The default assignment ensures the parameter is definitely assigned even when no item matches. The caller cannot rely on the value being meaningful when the method returns false, but the compiler guarantees it is not unassigned.

There is no boxing or reflection cost introduced by the out parameter itself. The parameter is a reference to the caller's storage location, and assignment writes directly to that location. For value types, the value is copied into the caller's variable; for reference types, the reference is copied. The generic machinery may introduce a small indirection for value types, but the out mechanism itself is the same as for non-generic methods.

Comparing out, ref, and Return-Value Approaches

When a generic method needs to return both a success flag and a value, there are three common designs:

The tuple approach is often cleaner for new code because the return type drives inference:

public static (bool Success, T Value) TryFind<T>(
    IEnumerable<T> items,
    Func<T, bool> predicate)
{
    foreach (var item in items)
    {
        if (predicate(item))
        {
            return (true, item);
        }
    }
    return (false, default);
}

The caller writes:

var (success, value) = TryFind(numbers, n => n > 10);

Here T is inferred from the items argument, and the tuple elements are typed accordingly. This avoids the explicit type argument requirement that a standalone out-only generic method imposes. Choose out when you want to match the established TryGetValue convention in a library API; choose a tuple when you control the API shape and want clearer call-site ergonomics.