Interop with C# Union Types and Closed Hierarchies

[T-Gro]

I propose we add interop support between F# discriminated unions and C#'s upcoming union types / closed hierarchies, enabling exhaustive pattern matching across the language boundary in both directions.

Full design discussion: [https://github.com//discussions/1463]

Why a separate discussion? C# unions is not one feature — it's a broad umbrella of 10 interlinked proposals (type unions, closed hierarchies, closed enums, case declarations, standard unions, target-typed access, inference features, type-value conversion). On the F# side, discriminated unions compile to 7 different IL layouts depending on case count, struct/ref, and attributes — each with different interop characteristics. The resulting matrix of "which C# feature × which F# layout" is too large for a single issue thread. The discussion has per-topic threads so each combination can be discussed independently.

The existing way of approaching this problem in F# is manually calling .Value on C# union types with no exhaustiveness, and C# consumers using .Tag switch + casts on F# DUs with no exhaustiveness.

Scope

This covers F#'s response to the C# union feature family:

C# Feature	F# Action	Discussion
Type unions (on Roslyn main)	Recognize [Union], auto-unwrap Value, exhaustive match	Topic A
Closed hierarchies	Recognize [Closed], emit [Closed] on F# DUs	Topic B
Closed enums	Recognize + declare [<Closed>] enums	Topic C
Case declarations	Covered by closed hierarchies	Topic D
Standard unions (Union<T1,T2>)	Relationship to Choice<'T1,'T2>	Topic E
Target-typed access	open type + possible F# equivalent	Topic F
Type value conversion	Type-as-value resolution	Topic G

Also related: target-typed inference, ctor inference, pattern inference — F# already handles these.

C# umbrella issue · proposals overview · Roslyn test plan (notes "Ping F# as FYI")

Pros and Cons

Advantages: Exhaustive pattern matching across F#/C# boundary. F# stays current with .NET. Natural extension of F#'s existing DU strength.

Disadvantages: Compiler complexity. C# spec still in preview (risk of churn).

Extra information

Estimated cost (XS, S, M, L, XL, XXL): L

Related suggestions:

• #538 — Erased type-tagged anonymous union types
• #1215 — Kotlin-like sealed classes
• #1052 — Safe enums
• #902 — Deconstruct on DUs for C#
• #606 — Typed union cases

Affidavit (please submit!)

Please tick these items by placing a cross in the box:

• This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
• This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it
• I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

• This is not a breaking change to the F# language design
• I or my company would be willing to help implement and/or test this

[T-Gro]

I did the deconstruction into many umbrella'd topics to show that "Will F# support C# unions" is not a simple binary question, and I would love to see feedback on what aspects will matter to you, F# users, the most.

Implementation-wise, making a subset of F# unions (not all!) consumable using the new C# exhaustive subtype matching is the straightforward starting point without much risk. But is that what F#ers want the most?

[August-Alm]

The use of union types is bound to become pervasive in C#. If F# is to continue to piggyback on the C# ecosystem, I consider it a must that we can consume C# DUs as if they are F# DUs. If this cannot be ensured, I foresee that F# as a language will die. A melodramatic assertion, yes, but I'm wholly convinced of it. Interop the other way, C# consuming F#, is much less of a concern.

Please, please, please make this work. Even if it breaks backwards compatibility, it's worth it. The divergence between F# option types and the C# evolution of ?-types is painful enough. This is an existential threat!

[T-Gro]

The goal is for sure to make it feel as natural as possible, but fundamental differences (like F# being discriminated unions, whereas C# took the "tagged by the System.Type" approach) can lead to different ergonomics.

The primary goal should be to enable a good ergonomics for the vanilla union declared via the pubic union Pet(Dog,Cat) syntax. Arbitrary unions will come with some challenges that might clash with correctness (e.g. that a union can be empty, i.e. not carrying any case. Or even be mutable, by replacing the case it carries at runtime).