I like the idea of supporting steps in ranges in general! The path to supporting it in range *literals* with special rules for guard, match, and normal contexts seems a little rough, but I can't think of a better way than what's been proposed so far.
x..y//z seems like a reasonable syntax to me. *"One nice bonus about 1..9//2 is because we can actually think that it is cutting the number of elements in 2, by some approximation"* — agreed, is has a nice divisible/modulo feel to it. ———————— I know that doing this work just to interpret x..y when x > y as an empty range is not the only motivator of this proposal, but a contributing factor. This is specifically for the bounds-checking errors in the common scenario x..y when is_literal(x) and is_variable(y), right? Specifically: for i <- 1..n, do: # zero times when n = 0 This feels like we're hacking around the lack of a notion of inclusivity/exclusivity; have we considered syntax around that instead of/as well as step notation? For example, using a comma "," to indicate an exclusive (rather the inclusive ".") boundary of a range. In the common case above, it seems like we could more accurately model the programmer's real intent: defining a dynamic zero-exclusive range; ex: for i <- 0,.n, do: # zero times when n = 0 I believe we could still make this syntax work with all the compile-time, pattern-matching, and guard-expressivity that ranges have today. 0,.0 -> [] 0,.1 -> [1] 2.,4 -> [2, 3] 2,,4 -> [3] Not to derail the step discussion—but it does seem like on-topic insofar as the motivations of the step feature is concerned? On Monday, March 22, 2021 at 9:46:16 AM UTC-7 José Valim wrote: > The proposal has been updated in the gist > <https://gist.github.com/josevalim/da8f1630e5f515dc2b05aefdc5d01af7> for: > x..y//z. > > >> Since we're bike shedding on the syntax, I would throw my hat into the >> ring for >> 1..10:2 >> > > It was commented before but the syntax above is ambiguous due to the use > of atoms and keywords, for example: x..y:z. > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/f6221657-7bd7-4f77-9917-157da64d7509n%40googlegroups.com.
