cursory investigation in checker.ts seems to suggest this problem would not apply since it looks for delimiters first

it's an interesting analogy to the performance of `.*.*` though I hadn't thought about that.

regardless of the perf impact I definitely value visual clarity so if there is a way to remove redundant ${string}s that isn't too expensive I'd do it (as is already the case most of the time)

Honestly I don't expect this to be used to validate literals very often because it's not a full guarantee the regex will be satisfied anyways.

The types are mostly a way to visualize expressions and to provide narrowing via `.test`

it can parse very long expressions without much problem but these combinatorial sequences are the way to blow it up if that is your goal

hmm I'm not sure there are a ton of cases that are simplified by initially not creating `${string}${string}` but it could be worth looking into what the cost of a final pass like that would be. potentially a lot for what is mostly a cosmetic improvement but happy to be proven wrong

the cases that begin with `${string}${string}` should be avoidable I'm interested to double check why that's going on.

unfortunately for a case like this, I tested doing the check that would be necessary to avoid `${string}${string}` an it's a huge performance hit

yeah generally that is avoided but there are some cases where if you already have `prefix${string}` there's no way to performantly check that appending another `${string}` is a no-op so it's irrelevant

when I was this I was like "no way it's way too long" but it actually worked instantly 🤯

obviously the inference is going to be less useful for clarity with this number of branches but the capture groups seem like they work?

😬 would be interesting.

I'm pretty confident in the inference (although happy to be proven wrong) but depending on the complexity of the expression it's going to hit a wall at some point.

Unfortunately, the APIs required for that aren't available for that yet (someone in the ArkType Discord was just looking into this a few days ago).

Eagerly awaiting support for some of those introspection + instantiation capabilities @typescriptlang.org 🙏

I don't know anything about atproto but the type-level string parsers I've worked on for @arktype.io's type syntax and the upcoming @ark/regex are very generalizable!

Also iirc @tylur.dev mentioned he was working on something related to this and Standard Schema?