Response to this range syntax proposal:
@Richard Feldman said:
idea for a way to fix for all of these: just actually do numeric range syntax, and have it return a
Range. so inclusive range looks like Rust's:1..=5...and so does inclusive:
1..5the exclusive one would return a value of type:
Iter(num) where [ num.from_literal : ..., num.plus : ..., num.lt : ... ]
I admit naming ranges with methods is hard. But if we can, that enables this idea, which would make the range syntax not needed:
What if we make compile-time resolvable iterators coerce to patterns when put into match statements? I'm not going as far as to suggest a to_pattern method, which returns the Pattern data-structure, but rather a language feature that works only with Iters (of certain types) . Each element would be OR- ed together. There's no pattern extraction, just like with ranges.
fib_nums_up_to = |upper_bound| ... # returns an Iter
is_small_fib = match num {
fib_nums_up_tol(10) => True,
_ => False
}
this is the same as this code:
is_small_fib = match num {
0| 1| 2| 3| 5| 8| 13| 21| 34 => True,
_ => False
}
This code has the benefit of compiling to a jump table. Would only work on elements that are byte-for-byte comparable. It's not good enough to have an equals method implemented as that would invalidate the jump-table approach, falling back to a potentially long chain of if statements the user probably doesn't want.
On the upside, it would work on Iters returning structs, tuples (would there be benefit here for working with matrices?), Non-recursive tag unions. ... and of course we're no limited to contignous ascending numbers.
We're not here to solve the halting problem, so we could set an iteration limit based on some LLVM or CPU architecture constraints, after which the user would get an error saying
Error - Pattern limit exceeded:
Matching for equality on more than 10000 individual patterns
created from Iter. Does the Iter have an end condition?
Hint: This is the same as if you were to list out all the 10000 patterns individually in source code.
If you want to match on a range, consider using a match guard:
match num {
a if a < 100 => Small,
a if 100 < a <= 200 => Average,
_ => Big,
}
A message was moved here from #ideas > range syntax/type by Norbert Hajagos.
I think that idea is decoupled
(from range syntax I mean)
regardless of range syntax, we can in principle allow "call functions in patterns" and also separately can in principle allow "iterators in patterns"
I'm not sure if we should, but we could :smile:
Well, if I think about it, even my suggested guard if-s have different semantics than this "iters in patterns". So yeah, the idea is decoupled, just came to me when reading your thread.
Last updated: Jun 16 2026 at 16:19 UTC