# Pattern matching + Enum proposals

**URL:** <https://forum.modular.com/t/pattern-matching-enum-proposals/3473>\
**Category:** Language Design\
**Tags:** discussion\
**Created:** [September 7, 2026, 2:54am UTC](https://forum.modular.com/t/pattern-matching-enum-proposals/3473 "2026-09-07T02:54:29Z")\
**Posts on this page:** 1\
**Showing post:** 56

<div class="post-metadata">

**Author:** ![Nick](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/nick/32/115_2.png) [@Nick](https://forum.modular.com/u/Nick)\
**Post date:** [October 17, 2026, 1:00am UTC](https://forum.modular.com/t/pattern-matching-enum-proposals/3473/56 "2026-10-17T01:00:00Z")

</div>

@clattner I have a simplified proposal that is actionable immediately, and still preserves the future opportunities that Owen and I care about.

When you wrote your initial PR, you required case fields to be **named.** You later changed your mind. Here’s what you said:

> [@clattner](#):
>
> I think there might be some confusion here, which is my fault. I wrote the proposal like this:
> 
> ```sql
> enum Token:
> case eof
> case identifier(value: String)
> case integer(value: Int)
> case source_range(start: Int, end: Int)
> 
> ```
> 
> But as I think you’re pointing out, tuples don’t have names on them.

In short: **I think the syntax in your initial PR was the right choice!** It’s just the desugaring we need to iron out.

Let’s repaint my `case struct` syntax using your original syntax. For reference, here’s `case struct`:

```auto
enum Color:
    case Red
    case Green
    case Blue

    @fieldwise_init
    case struct RGB:
        var r: Int32
        var g: Int32
        var b: Int32

    @fieldwise_init
    case struct HSL:
        var h: Int32
        var s: Int32
        var l: Int32

```

We can repaint it using your original PR’s syntax as follows:

```auto
enum Color:
    case Red
    case Green
    case Blue
    case RGB(var r: Int32, var g: Int32, var b: Int32)
    case HSL(var h: Int32, var s: Int32, var l: Int32)

```

That’s a lot more concise!

I’ve made one small change to your original syntax: I’ve added `var` in front of each argument. This seems important for a few reasons:

- It matches the syntax of field declarations in structs: we declare fields using `var`, to indicate ownership.
- It reflects the signature of `Color.RGB. __init__ `: the initializer takes ownership of its arguments.
- It leaves open the possibility of supporting trait conformances on cases, e.g. `case Foo(var x: Int)(SomeTrait)`. The presence of `var` in the field list makes it clear to both human readers and Mojo’s parser that the first bracket introduces a field list, not a trait conformance list.

Some day, we might also want to use this `var` syntax as shorthand for declaring structs that have the `@fieldwise_init` decorator. This makes the `case` syntax “less special”:

```auto
struct Point(var x: Int, var y: Int)

var p = Point(0, 0) # fieldwise initializer is available

match p:
   case Point(x=a, y=b): ... # pattern matching is available

```

For the `enum` MVP, this covers all of the _syntax_ that Owen and I need as the foundation for a future “type-based” treatment of enum cases. If you were to ship this syntax (i.e. the syntax of your initial PR!) for the MVP, we leave open the possibility of (some day) pursuing the [opportunities](https://forum.modular.com/t/pattern-matching-enum-proposals/3473/38#p-10061-opportunities-provided-by-this-design-post-mvp-2) I presented in my feedback post, without needing to redesign the syntax and mental model of enums to accommodate it.

For the MVP, I don’t really mind whether each case desugars to its own type or not. You can implement whatever desugaring you already had in mind. My goal is just to have the MVP design be forward-compatible with the opportunities Owen and I presented. The above syntax sets us up for that. All I need is for the components of each case to be “field-like”, i.e. accessible by name, rather than being “Tuple-like”.

---

_[View the full topic](https://forum.modular.com/t/pattern-matching-enum-proposals/3473)._