Feature request: infer literal value types for captures

[Raiondesu]

Currently, when parsing regexes with captures, their types are inferred as either string or string | undefined depending on the capture definition.

However, there are many simple use-cases that would benefit from analyzing captures more literally and having stricter typing for their values:

const fruit = typedRegExp('(banana|apple|pear|orange)');

const banana = fruit.exec('banana')![1];
// Currently typed as:
// string

// Could be typed as:
// 'banana' | 'apple' | 'pear' | 'orange'

// But since we know the type of the string, it could be typed as just:
// 'banana' | 'apple' | 'pear' | 'orange' & 'banana' -> just 'banana'
// This is, however, unrealistic for more complex patterns...

[codpro2005]

Hello! This is indeed one of the biggest missing features in the library. Strict literal patterns like these could be represented relatively simply, but supporting more complex patterns would introduce significant additional complexity. And Once I've commited to string literals, I’d also be required to handle more complex cases to ensure no true positives are accidentally excluded. For that reason, including some practical limitations that may often warrant fallbacks to string, I've decided not to add them as of now as the complexity and effort I'd have to put into this project is too large.

While I may not add this in the future either, there's very good news as a month ago David Blass added ArkRegex to his ArkType library. The goal of that project is similar to mine but he committed to many missing pieces like error messages (including best regex practices), and string literal sets for regex patterns. Since he's much more active in the OSS scene I'd assume he'll maintain it a lot better too.

[Raiondesu]

Thanks for such an in-depth reply and pointers to relevant libraries! I'll take a look.

Taking everything into consideration, this feature truly does seem out of scope.

[codpro2005]

I wouldn’t necessarily say it’s out of scope! It’s a genuinely good idea — just a bit too large for me to take on right now. And since ArkRegex already handles this area really well, there’s also less pressure for me to implement it here.