Richard Feldman (Aug 25 2024 at 20:44): Richard Feldman (Aug 25 2024 at 20:44):I just realized that these are essentially equivalent in terms of what they match and how they'd be implemented:
[..start, 'a', 'b', ..middle, 'c', ..end] ->
"$(start)ab$(middle)c$(end)" ->
both would be nice for things like parsers and especially URL matching
Richard Feldman (Aug 25 2024 at 20:51):e.g.
when url is
"/users/$(userId)/posts/$(postId)/edit" ->
Can this be implemented in an efficient way?
Ayaz Hafiz (Aug 25 2024 at 21:27):you'd need to implement this as basically a regex right?
Richard Feldman (Aug 25 2024 at 21:33):naively it would be, for each pattern:
'a' above) Richard Feldman (Aug 25 2024 at 21:34):a smarter version of that would avoid redoing work based on knowledge of the patterns in the other branches
Richard Feldman (Aug 25 2024 at 21:36):e.g. if two patterns both start with "foo$(bar)baz and the first pattern matches all of that but then fails later, the second pattern should be able to pick up where the first one left off rather than having to re-match the whole thing from scratch
Richard Feldman (Aug 25 2024 at 21:37):this would be nontrivial to implement in the compiler, but a sweet benefit of it is that userspace code would use it for the ergonomics and then get generated code that's way more efficient than what they'd likely get if they used any other ergonomic alternative
Brendan Hansknecht (Aug 25 2024 at 22:26):Yeah, I think we should support this. It is equivalent to an exceptionally limited version of regex, but I think that is a good thing. Just the most basic and sane pattern that is static.
Brendan Hansknecht (Aug 25 2024 at 22:27):Just have to decide some capture/association rules (which we could follow .* regex groups for).
Brendan Hansknecht (Aug 25 2024 at 22:28):Like how do we want it to match with duplication:
To be specific, we need to define the captures for this:
/users/joe/posts/posts/27/edit
Richard Feldman (Aug 25 2024 at 22:29):I think the only reasonable option is to eagerly match on whatever is hardcoded in the pattern
Richard Feldman (Aug 25 2024 at 22:29):so in that example, since /posts is written out in the pattern, the first /posts matches and then the second one goes into the variable (duplicates don't matter)
Brendan Hansknecht (Aug 25 2024 at 22:29):That is probably the best for performance.
Richard Feldman (Aug 25 2024 at 22:29):this is the fastest algorithm
Richard Feldman (Aug 25 2024 at 22:29):yeah exactly
Brendan Hansknecht (Aug 25 2024 at 22:30):Sounds good :+1:
Richard Feldman (Aug 25 2024 at 22:30):yeah, the other thing I like about it is that it's basically not new syntax
Richard Feldman (Aug 25 2024 at 22:30):just making existing syntax work in more places
Richard Feldman (Aug 25 2024 at 22:30):we'd actually be removing a compiler error ("interpolation isn't allowed in patterns") and making it do something awesome instead :grinning_face_with_smiling_eyes:
Sven van Caem (Aug 26 2024 at 11:34):Richard Feldman said:
I just realized that these are essentially equivalent in terms of what they match and how they'd be implemented:
[..start, 'a', 'b', ..middle, 'c', ..end] ->"$(start)ab$(middle)c$(end)" ->
I thought list patterns were only allowed to contain one ..rest pattern to avoid ambiguity on what it matches?
Richard Feldman (Aug 26 2024 at 12:39):that's true today, but this is an idea for how to usefully remove that restriction :big_smile:
Trevor Settles (Aug 27 2024 at 00:57):This looks neat! I think I'm answering my own question here, but how would type annotations work here? If I understand correctly, we wouldn't need type annotations. This would only work for strings, since what it de-sugars to would be a List of Strings, correct?
Richard Feldman (Aug 27 2024 at 02:09):I think this pattern matching could work for both arbitrary lists with .. and also for strings with the interpolation syntax - it would be the same algorithm either way
Richard Feldman (Aug 27 2024 at 02:09):just a question of whether it's looking at elements in a list or bytes in a string
Last updated: Jun 16 2026 at 16:19 UTC