Exhaustive parsing of enums with associated values

[lukeredpath]

The library makes it fairly easy to parse some input into cases of an enum with associated values, albeit with a bit more work than raw representable enums. For example, given this structure:

enum WrappedValue {
  case int(Int)
  case string(String)
}

We can parse input in the form "type:value" e.g. "int:123" into WrappedValue.int(123) using the following parser:

OneOf {
    Parse(.case(WrappedValue.int)) {
        "int:"
        Int.parser()
    }
    Parse(.case(WrappedValue.string)) {
        "string:"
        Prefix { !$0.isWhitespace }.map(.string)
    }
}

One thing that would be really nice would be to have some kind of dedicated enum case parser - effectively a special case of OneOf that enables exhaustive checking, i.e. that you have handled every case of WrappedValue in the parser. This would have to be a runtime warning rather than a compile-time check but I still think this would be useful.

My inspiration here is the SwitchStore in TCA that warns you if you do not exhaustively handle each case and this could probably borrow implementation ideas from there too. Like SwitchStore, it would require some generated variadics to handle different numbers of cases.

Hypothetical syntax:

let wrappedValue = CaseOf(WrappedValue.self) {
  Case(WrappedValue.int) {
    "int:"
    Int.parser()
  }
  // etc.
} // runtime warning emitted that case `.string` is not handled.

var input = "int:123"
try wrappedValue.parse(input) // outputs: WrappedValue.int(123)

[stephencelis]

Hey @lukeredpath! Thanks for the suggestion!

I think functionally, OneOf already kind of operates as you would expect because if a parser for a particular case isn't listed inside, it will fail to parse, right? If that's true, is the main thing you're suggesting an alternate syntax for improved error messaging, i.e. an error that lets the programmer know they forgot to write a parser?

If so, that definitely sounds like a nice custom parser, but it's a surprisingly nuanced problem. With SwitchStore we're lucky that we already know the case we need to match on (it's the case that lives in the store's state). But with parsing, we're in the opposite predicament: we don't have a concrete case to work with, instead we need to somehow rule out all of the enums cases as we attempt to parse each given one.

I'm actually not even sure this is technically possible, but if I could take some of our learnings and help sketch out some of the known requirements:

1. We'd need to leverage the Swift runtime metadata to reflect on an enum and fetch all of the tags for each case.
2. The CaseOf parser would need to introduce some local state that somehow accumulates these tags that are matched against in its builder block (this is what I'm not sure is possible, as you can't know the "tag" of a case path or embed function)
3. Such state accumulation might require a custom result builder that knows how to enhance each Case with this work

This is just the surface of what sticks out to me, if you choose to go down the path of discovery. Unfortunately I'm just not certain it's possible 😅