C# 14 - Extensions with different generic parameters on the extension and the method cannot infer the types independently

[FreeApophis]

We have an Option<T> monad (implemented as a struct) and we would like to have something like OfType<T> implemented as an extension on it.

So far, you couldn't simply implement such an extension on a generic type because C# does not support partial type inference on generic methods. Something like below was possible, but you always have to give both types, even though TItem can be inferred by the given option. And that is utterly inconvenient.

    public static Option<TResult> DownCast<TItem, TResult>(this Option<TItem> option)
        where TItem : class
        => /* implementation detail*/

There are alternatives you can use to partially get what you want:

• Implement it on Option<T> directly not as an extension.
• Implement it on a non-generic interface like IOption (That actually is the way OfType<T> is implemented on IEnumerable)

Fast forward to C#14 - now we can define the extension independent of the Method, so I thought now this could finally be done.

So I tried the following:

public static class OptionExtensions
{
    extension<TItem>(Option<TItem> option)
        where TItem : class
    {
        public Option<TResult> DownCast<TResult>()
            where TResult : class
            => /* implementation detail*/
    }
}

This can be implemented, and it compiles perfectly fine.

But if I try to use the method, I do get a compilation error:

object obj = "Hello, World!";
Option<object> option = Option.Some(obj);

Option<string> stringOption = option.DownCast<string>();

The error is the same as if the extension wouldn’t exist at all.

error CS1061: 'Option<object>' does not contain a definition for 'DownCast' and no accessible extension method 'DownCast' accepting a first argument of type 'Option<object>' could be found (are you missing a using directive or an assembly reference?).

i checked if it is just an accessibility problem, but if I implement a non-generic extension like "HasValue"

So I have multiple questions, is that a Bug and where could I report that?

• Is that a bug in the specification?
• Does anyone know if the specification says anything about such a scenario, or did really nobody think of it?
• Or is this a bug just in the implementation?
• Where would I report this defect (specification, implementation)?

I have the bad feeling that this was overlooked because this was not possible before and nobody tried it.

I use the latest preview.

PS:
After Writing all this, I thought I should check if the compiler would find the method if I give it both generic arguments, like in the sad past.

Option<string> stringOption = option.DownCast<object, string>();

And it worked, this compiles, but it is very say... and totally counter intuitive. Generic type-inference is so bad in C#, and this is really a missed opportunity.

I am convinced that the generic type argument on the extension and the method should be inferred independently. I do not see a reason why you couldn't do that inference independently.

I consider this a major design flaw... did nobody try this?

[333fred]

I consider this a major design flaw... did nobody try this?

This was discussed many times:

• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-10-02.md#extensions
• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-10-07.md#extensions
• https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-10-14.md#extensions
• https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-02-19.md#extensions
• https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-02-26.md#extensions
• https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-05-05.md#single-phase-consequences
• Probably more, I didn't go through every one of our meeting notes.

[CyrusNajmabadi]

This is also something we've explicitly indicated we're interested in improving. But it was more important to us to not bifurcate teh classic and modern extension space right from the start. So modern extensions work the same way as classic ones do at least initially. There's nothing stopping us from having improvements there in the future.

[martin-steinhoefer]

Did I told you, that many developers would fall into the trap the misleading syntax lays out?

[FreeApophis]

Thank you very much for the references, it's sometimes tricky to find the relevant discussions since they are obviously done at different places.

@martin-steinhoefer it seemed just natural, and it would be so handy.

[jnm2]

One potential way forward would be for extensions to be placed inside a generic class whose type parameters all appear within the receiver type for the extensions. Then TItem could be inferred in a separate phase and TResult would be the only type parameter on the method. The extension author would be opting into breaking with the past in this two-phase approach by putting the extension inside a generic class.

[martin-steinhoefer]

Hi there,

I do agree, the inability to separately infer the type parameters of the receiver (which should always be possible) is a serious limitation. But this has been sacrificed over backwards compatibility. And although the team signalizes, that there may be work done in the future regarding the problem - I personally think, it will never make it - wich is sad.

The team thinks, that partial inference could solve the problem, but it does not: none of the proposals, that have been made until now, is able to truly reduce the number of type parameters - you don't have to specify types, that can be inferred (which is a great feature btw!), but the number of type parameters stays the same (because there is no notion of which non-inferred (actual) type parameter goes actually to which declared type parameter - in a sense all proposals go for positional type parameter matching - maybe that is because type parameters don't have a parameter name).

The team also considered a 2-phase inference (which could have solved the problem) - as was specified for extensions in C#3 in the past (but actually something else was implemented) - but considered this a breaking change, which they didn't want (given the vast amount of existing code). Unless that opinion changes, I don't see that 2-phase inference coming.

Does anybody know of a general generic implementation of the Cast<T,TResult> operator (not restricted to reference types)? I guess, there is a reason, why the authors of System.Linq.Enumerable used the approach via non-generic IEnumerable...
So my advice would be - go for the non-generic interface and implement the extension for that interface - that is the best compromise you can get right now (it works for all reference types as expected and for value types as long as T==TResult).

[jnm2]

By "break" we mean "no library could actually safely move any existing generic extension method to the new syntax." That was unpalatable. We decided the compiled output should include an emitted method that is exactly the same between the classic syntax and the new syntax.

[En3Tho]

Again, I think the point here is that:

1. You have to think of new extension mechanism as an "extension" to the old one. E.g. old extensions + properties + static members. Cool.
2. The goal was for the library authors to be able to simply update their packages with new extensions without breaking literally anything
3. There is still a hope that 2-phase inference will make it
4. As a user I totally get your frustration because that could simplify some of my internal apis greatly. That said I think it's better to have these extenstion properties and static member than not.

[CyrusNajmabadi]

but you still are too afraid to move forward with better functionality

As we said, we would like to have better inference here. Our goal is a best of all worlds. Extensions aren't left behind, or bifurcated into 'legacy' and 'modern' (a painful state for tons of libraries out there with deep investments in C# 3.0 extensions), and we can have better inference.

if you OPT-IN for the new syntax? Voluntarily OPT-IN.

This is a negative. We do not want people to pay a negative price for moving forward. That often makes ecosystems break. A significant amount will stay behind, which also means they are less ok with then using the modern options (since keeping around both together is an unpleasant mishmash of old and new).

--

The approach we took optimizes for allowing almost everything to move forward without risk. And it then allows us to improve things uniformly for that whole new system.

I can see why you do not like this in the short term. Especially if you care mostly about the inference case, and do not care about bifurcation. However, our views here are long term and we are trying to ensure we can get both without leaving any groups behind.

martin-steinhoefer is right, this is worse than C++, you will never fix this.

We have literally stated it is a high goal for us to make inference work a lot better here, and we see ways that should make that very possible.

[jnm2]

I wish there had been a "basically free, no incompatibilities" option! I hear your deep frustration. You really wanted a fresh start.