Jasper Woudenberg (Jul 11 2026 at 10:20): Jasper Woudenberg (Jul 11 2026 at 10:20):I'm looking to support the ..< and ..= operators for my date/time library. This requires implementing the inclusive_range and exclusive_range methods, which in turn depend on the type defining is_lt and is_lte respectively. I was wondering if the contract could be changed to remove this dependency.
Implementing the range-builder operators for Date and Time works great. However, I'd also like to implement them for Month and Weekday, so it becomes possible to do Oct..<Feb, which should return an iterator that in turn yields Oct, Nov, Dec, and Jan. Because months and weekdays form a cycle there isn't an is_lt or is_lte that would yield the result I want.
I think there's two possible alternatives. One would be to take instead require is_eq. Another would be to depend on this type of iterator having an upfront-known length. In that case the iterator could simply count down and not need a comparison function (nor steps_between, while we're at it).
What do you think?
Luke Boswell (Jul 11 2026 at 11:13):Didnt we talk about changing the api to something like is before and is after? I didn't really follow that thread closely
Luke Boswell (Jul 11 2026 at 11:13):Ah this PR maybe? https://github.com/roc-lang/roc/pull/9832
Luke Boswell (Jul 11 2026 at 11:14):@Jonathan I think was working on that
Jonathan (Jul 11 2026 at 11:22):Ah, hello. I might have forgotten to keep up with that, will do this afternoon. But even so I don't think that answers Jasper's problem: regardless of the lt/cmp api, Friday..<Monday is tricky because Monday is canonically "before" Friday, but "after" in this particular iterator. I don't even think it makes sense to implement comparison or "lt" for abstract days of the week.
Jonathan (Jul 11 2026 at 11:26):In theory I would think that "inclusive_range" is something that needs
add_try constraint)Which I believe is in agreement with Jasper.
Last updated: Jul 23 2026 at 13:15 UTC