const/literal handlers

[zacaj]

Is your feature request related to a problem? Please describe.
When trying to use ts-pattern to match cases to a string type union (eg, 'case-1' | 'case-2'), the syntax is unnecessarily verbose. I need to write () => every time, and then also add as const after each value, or repeat the options in returnType<...>() to get a proper type out

Describe the solution you'd like
It would be nice if the types for handlers accepted either a function with a given return type OR a value with that type, in the case where no data from the matcher is needed, and thus ts-pattern would have access to the specific value instead of just string to determine its returnType implicitly.
Add any other context or screenshots about the feature request here.

[zoontek]

@zacaj Your issue is not super clear (no code example), but it seems what you want already exists: P.union

[zacaj]

P.union isn't related to this. That matches const cases, I want const outputs.

To butcher an example from the readme, I want to pattern match to the type 'ERROR' | 'CONTENT' | 'SRC'. So I do:

const html = match(result)
  .with({ type: 'error' }, () => 'ERROR')
  .with({ type: 'ok', data: { type: 'text' } }, (res) =>'CONTENT')
  .with({ type: 'ok', data: { type: 'img', src: P.select() } }, () => 'SRC')
  .exhaustive();

But that gives me an html: string, so I then need to use .returnType<'ERROR' | 'CONTENT' | 'SRC'>() on it too, which repeats the type union even though it's already derivable from the return values of the cases.

And they shouldn't need to be return values, because it's a function which returns a constant, so I should be able to do

const html = match(result)
  .with({ type: 'error' }, 'ERROR')
  .with({ type: 'ok', data: { type: 'text' } }, 'CONTENT')
  .with({ type: 'ok', data: { type: 'img', src: P.select() } }, 'SRC')
  .exhaustive();

and have html's type derived correctly while also having a more readable pattern match since there aren't a bunch of spurious () => involved

[gvergnaud]

Thanks for the issue. Unfortunately, inferring a literal from the return type of a callback isn't possible in the current version of typescript, as this playground demonstrates.

Regarding supporting plain values instead of functions, I don't want to allow this for reasons outlined in this issue.

[zacaj]

The inability to infer the literal from the callback is exactly why I want to be able to just use a literal without needing a callback

I'm not sure I see the connection between your link comment and this- your comment is specifically talking about function calls and fallthrough, but neither of those are a problem with a literal constant?