Feature focus in the C# 16 cycle

[MadsTorgersen]

Feature focus in the C# 16 cycle

Here's where I believe we should apply our resources over the next year or so.

Unsafe v2

• https://github.com/dotnet/csharplang/blob/main/proposals/unsafe-evolution.md

This is major feature work that is already ongoing. The dependencies up and down the stack are significant, and we should expect to keep tweaking aspects of the feature for a while based on feedback and experience.

That said, most users will only be indirectly affected by the changes to unsafe. It is going to improve the safety of critical code, but not the coding experience of most developers.

void M()
{
    int i = 1;
    int* ptr = &i; // Allowed: creating a pointer is not itself unsafe
    unsafe
    {
        Console.WriteLine(*ptr); // Dereference of memory not managed by the runtime. This is unsafe.
        ref int intRef = Unsafe.AsRef(ptr); // Conversion of memory not managed by the runtime to a `ref`. This is unsafe.
    }
}

namespace System.Runtime.CompilerServices
{
    public static class Unsafe
    {
        unsafe public static ref T AsRef<T>(void* source) { /* ... */ } // `unsafe` marks the member as *requires-unsafe*.
    }
}

Dictionary expressions

• https://github.com/dotnet/csharplang/blob/main/proposals/dictionary-expressions.md

Dictionary expressions were intended to go into C# 15 but won't quite make it. We should get it over the finish line.

Dictionary<string, int> nameToAge = ["mads": 21, existingDict.MaxPair(), .. otherDict];

Closed enums

• https://github.com/dotnet/csharplang/blob/main/proposals/closed-enums.md

Closed enums is the last of a trio of features focused on exhaustiveness, with unions and closed hierarchies making into C# 15. This is a smaller feature to ensure enums are only used as intended, and pattern matching code handles all possible values.

public closed enum Color { Red, Green, Blue }

var infrared = Color.Red - 1; // Error, not a declared member

_ = color switch
{
    Red => "red",
    Green => "green",
    Blue => "blue"
    // No warning about missing cases
};

Type inference improvements

As we were designing unions, many possible next features were explored. I believe the most fundamental and broadly useful are around type inference: Using it in more contexts, and inferring more from those contexts.

Inference from more context

• https://github.com/dotnet/csharplang/blob/main/proposals/target-typed-generic-type-inference.md
• https://github.com/dotnet/csharplang/blob/main/proposals/type-parameter-inference-from-constraints.md
• Type inference between union and case types (not yet proposed)

The target type of an expression, when it has one, could supply useful information about the expected result type. In factory/constructor scenarios in particular, that is often the only place we would be able to infer type arguments from.

public class MyCollection<T> : IEnumerable<T> { ... }

public class MyCollection
{
    public static MyCollection<T> Create<T>() { ... }
}

IEnumerable<string> c = MyCollection.Create(); // Infer <string> from target type

In addition, constraints could be used to proactively make the right inference instead of just rejecting a wrong one after the fact.

void Display<TEnumerable, TElement>(TEnumerable elements) where TEnumerable : IEnumerable<TElement>
{
    Console.WriteLine(string.Join(",", elements));
}

List<int> l = [1, 2, 3];
Display(l); // Infer <List<int>, int>

Finally, for unions to fully benefit, inference should exploit the relationship between a union type and its case types the same way it does inheritance today.

Inference in more places

• https://github.com/dotnet/csharplang/blob/main/proposals/inference-for-constructor-calls.md
• https://github.com/dotnet/csharplang/blob/main/proposals/inference-for-type-patterns.md

Generic type inference currently applies only to the use of generic methods. We should use it also for type parameters to generic types, when they are instantiated or pattern-matched against. Unions and closed classes could significantly benefit.

Option<string> option = new Some("Hello"); // Infer <string>

if (option is Some(var text)) ... // Infer <string>

Declarative UI construction

• https://github.com/dotnet/csharplang/blob/main/meetings/2026/LDM-2026-07-15.md

The Windows team is exploring approaches to declarative UI construction in C#, and there are several ways that new language features would likely help. While these likely wouldn't be candidates for the C# 16 time frame, we should devote design resources to participate in this exploration for future benefit.

[hez2010]

I would also like to see revising two-phase lookup in extensions being added to C# 16 theme as well. Currently not being able to infer the type parameter of the receiver in a generic extension method over a generic type creates a very bad UX and pushes people away from using extensions in such scenarios.

There's a separate proposal that tries to use a discard for the type argument, which actually doesn't work well here becuase it prevents type composition and blocks most goodies that generic extensions can provide.

This also fit into the "Type inference improvements" category.

[MadsTorgersen]

I agree that would fit with other type inference improvements. We'd need a proposal.

[Richiban]

Are case classes / enum classes not on the list anywhere? It doesn't look like the design has settled so they won't make 15 but I'd be disappointed if they don't make the next version either.

[CyrusNajmabadi]

@Richiban It's something i'm championing.

[MadsTorgersen]

It's definitely on the radar, but the type inference features feel like they come first, and are almost prerequisite to make "enum classes" (or whatever we'd end up calling a discriminated-union feature) a good experience.

[MgSam]

I’m going to strongly disagree on the direction going forward here. I don’t think you guys can keep going on pretending the world hasn’t changed- it has. The reality is that the days of writing code by hand are essentially over. And LLMs don’t need features that save a few keystrokes here and there (Dictionary Expressions being a great example).

In my opinion, the value-add from the language perspective are areas where the language gets fundamental capabilities it could not do before (like the seemingly shelved extension interfaces), or areas where substantial expressiveness wins could be had. Frankly, I’m not sure any of these proposals qualify other than improved type inference.

[CyrusNajmabadi]

And LLMs don’t need features that save a few keystrokes

My own experience is that llms waste a lot of time when things don't work uniformly. I've seen this a lot when working on C# code bases pre-collection-expressions. LLM will rotate through several approaches just to make things compile. The more complex the code patterns (like for immutable containers) the worse it is. Having simple and consistent patterns for the llm to use seems to help things out a lot more as a one-size-fits-all approach means it doesn't need to follow specific patterns different domains.

gets fundamental capabilities it could not do before

Using your same logic, why would that bother an llm? All this stuff is turing complete. It's not like there are fundamental important problems that are unsolvable.

Frankly, I’m not sure any of these proposals qualify

I think we need more than your gut here. So far the llms are being trained on the code that users read/write. So far, they interoperate with users in all domains. So making the language better in the same way that makes it better for humans seems reasonable for llms as well.

[MgSam]

Is adding more ways to do identical things going to make LLMs more token efficient or less token efficient? Are you talking about the latest models or models from a year ago? The newest models almost never struggle with syntax (except around usings and ambiguity about what is and isn’t in scope- which there is no proposal to address)

Not sure where I implied we should make decisions on my “gut”. There is solid data on which languages are the most token efficient- AFAIK LLM efficiency has not been a topic of a single LDM so far- thus my point. The roadmap or workflow of C# design has not changed meaningfully while the role of C# is dramatically different than it was a year ago. Dictionary expressions (to pick on perhaps unfairly) were a marginal idea when proposed- a ton of work for a rare use case- now they are frankly silly to spend any time on given almost no one will ever be writing one by hand.

IMO, besides the rare cases where major syntax wins can be had, the “hard” features that require runtime or editor cooperation- that by and large get avoided so a yearly release schedule can be hit- are mostly the ones where there is still value add.

To call out one such pain point- writing analyzers / source generators remains a miserable experience- even for LLMs- with Visual Studio being stuck on Framework being a huge part of the reason. It’s been more than half a decade with no meaningful progress improving this experience.

[TheBenda]

I mean, following your argumentation we could just tell the LLM to write Byte Code, but that didn’t hit reality. One the one hand, LLM prices are skyrocketing, so maybe you will need your code by hand again. But I think making shorter and easier code to review gets even more important, as long as you aren’t turbo vibe coding and are just dumping code to prod

[pjmlp]

It isn't for lack of trying, Code Generation and Optimization 2022 Keynote: Compiler 2.0 and Programming Language Design and Implementation in the Era of Machine Learning come to mind.

As does the recent Frame: A New X11 Server Implementation Written Entirely In x86_64 Assembly, with Claude Code.

[siegfriedpammer]

Honestly, I don't think programming languages originally developed for humans should cater to LLMs, especially because code needs to be read and verified by humans. There are already efforts to develop programming languages for LLMs, if you do not need humans in the loop, those will be sufficient.

Also, IMHO, the fact that LLMs are using human language, is both the biggest blessing and curse at the same time. It's a blessing because any human being capable of speaking or writing can interact with LLMs, but also a curse, because all the inaccuracies and room for interpretation of human language affect the results it generates, also they are inherently non-deterministic, which is a different problem.

At some point, LLMs will probably develop their own, more efficient language to "think".

[davidroth]

I would kindly like to ask about the status of left join in query Syntax. When can we expect this to to be implemented?

It has already been approved, but still no signs of impl progress.

[CyrusNajmabadi]

Currently it is in the backlog.

[davidroth]

I saw that, but I was hoping to learn why this isn't getting any attention. What is the prioritization process for getting this onto the to-do list, and how are these decisions made? The original LDM note was:

We will proceed with this proposal, hopefully in the C# 14 timeframe (barring any other time constraints).

[CyrusNajmabadi]

but I was hoping to learn why this isn't getting any attention.

No one has prioritized it above all the other work they're doing.

What is the prioritization process for getting this onto the to-do list

The LDM has to decide it's more important than the rest of the things we're looking into getting into the next release.

(barring any other time constraints).

Yup. Other time constraints prevented this.

[IvanOvergaardSS]

I also think join + tuples in linq should be top prioritized.

[ds5678]

Could generic bridging (#6308) be investigated? The runtime feature that would make it possible is currently scheduled to be part of .NET 12.

[paulbartrum]

The UnsafeAccessor feature you say would enable generic bridging feels more like a workaround to make up for the lack of a proper first-class generic bridging feature. (I do agree that generic bridging would be really nice to have.)

[ds5678]

@paulbartrum dotnet/runtime#119876 (comment)

[paulbartrum]

Huh. Okay, I stand corrected.

[dotfede]

I've hit walls several times in the past due to lack of partial generic type inference:

TEntity FindByKey<TEntity, TKey>(TKey key) where TEntity: Entity<TKey>
{
   // ....
}

Given:

class Product: Entity<Guid>;

I would love to be able to do:

var product = FindByKey<Product>(someGuid);

since the TEntity type argument Product already constrains TKey to type Guid it seems like the compiler could be able to infer this, no?

I would love to see stuff like that in C#.

[rcollina]

Agree on this one; and we need this on the new extension-everything block as well.

[lloydjatkinson]

Declarative UI sounds interesting!

What about the Result/Option type constructs that were mentioned in one of the Union proposals?

[TETYYS]

it is unfortunate that due to historic reasons, the most desirable behavior for an enum is not going to be 'default'

[Russ-McClelland]

Inherited ctors please! There are numerous cases where these would be essential. In general, if a subclass does not implement new ctors, the compiler can infer a matching signature from the superclass (or superclass chain). If the subclass implements a different signature, invoking that signature invokes that implementation. Invoking a different signature would trigger the superclass resolution mechanism.

[gumbarros]

Sorry if this off topic, but is there a issue or plan for C# 16 to add top level extensions? (extension blocks without a parent class to save a tab)

[ufcpp]

I believe Top-level members include that feature. Is there a chance this will be included in 16?

[zvrba]

Focus only on (seemingly) low-hanging fruit, whereas #8870 has been stuck in limbo for years now.

[zvrba]

Unions have always been easy to emulate:

public abstract class MySum
{
    private MySum() { }
    public class Case1 : MySum { ... }
    // etc
}

The compiler could have even been enhanced to infer exhaustiveness in patterns due to private ctor on the base. So much noise about an already existing feature, though in disguised form.

The feature I linked to cannot be emulated (easily, if at all), as it's related to the internals of vtables.

[CyrusNajmabadi]

The feature I linked to cannot be emulated (easily, if at all)

That's part of decision making. But we still have to view the feature as being worth the cost. Currently that is not the case. If that changes (note: it would need a lot of community push for that), then it can be reprioritized.

[Richiban]

Unions have always been easy to emulate

Sort of, but it's not until C# 15 where we will get the closed keyword that you can really emulate them. After that it's just more-or-less some shorthand to be able to declare them with case (or whatever the final version is).

As far as C# features go, the remaining work on DUs is one of the smaller ones

[zvrba]

I don't understand why closed keyword is needed at all or why was it easier to implement than compiler analysis over visible ctors (would need no language change; re my example above).

[CyrusNajmabadi]

Closed has no bearing on the accessibility of constructors.

We don't think people should have to code to that particular pattern to get exhaustiveness.

compiler analysis over visible ctors

We don't think you need a private constructor (or an abstract base, or nested types). Indeed, that would prevent being able to have a simple closed hierarchy with normal types, all with normal constructors, all that are non nested. Which is what we think people should be able to do.

[Xenoprimate]

#2068 / dotnet/roslyn#45284 is still a pain point for me. Understand this probably doesn't have universal appeal but just wanted to prompt that at least one person (me) still has this on their radar.

[TahirAhmadov]

Count me in.

[Kuurama]

All of this is great but is adding unbound or partialy bound generics in type parameter aliases planned? #1239

I see it as something we might want more and more as people use Result<T, TErr>, as they could want to choose the TErr for their namespace globally.

[vladd]

1. As we have now a tool which can drive traits (default interface methods), are we going to make traits a first-class citizen?
2. Should we go further in the direction of type classes? Roles seem to have lost their momentum for now.

[jnyrup]

Relieved to read that the "declarative UI construction" rather seems to be a set of general language features that also benefits declarative UI construction.