<div dir="ltr">Researching the of deriving some iterable representations from ranges, and I am not here with the good news.<br><br>Unlike range algebra and boolean operations, which generalize extremely well, iterability of ranges... Well, it's safe to say it doesn't generalize at all. Analyzing key features people expect iterable ranges to have, I ended up concluding there are basically two groups / two use cases for them. First is plain and simple, arguably the most popular one: iterating over a range of integer numbers, i.e. `for (i : Range.of(1, 10))`. Another use case is for more complex iterations over ranges of reference types, most commonly dates/time.<br><br>There are two groups of values by their nature: 

discrete

 and continuous. Most of the types belong to the second group, as there is no direct increment AND decrement for them (we will omit hardware limitations for simplicity), such as floating point values. What is the increment of 1,3? 1.31 or 1.30000000001, or maybe something even more unreadable? On the other hand, the increment of LocalDate in context of range iteration that represents today is rather obvious - it is tomorrow.<div><br></div><div>There is a pretty limited number of discrete types in jdk. Dates, whole numbers and basically that's it. The discrete types that are not present in jdk can be really various. For example, users can define a comparable type "F1Team" and compare them based on their position in the last race. There, increment would most likely be the next team in rating. There are many domain-specific cases like this.<br><br>This is where the problem comes from. If the user would always have to pass a comparator to create a range, it would be consistent to make the user define increment/decrement as well. But we don't want users to pass a comparator if the type is already comparable. Similarly, we don't want users to define increment/decrement if there is already one in the language! I think defining increments for dates (say LocalDate.plusDays(1)) would be acceptable, even defining increments for floats in context of ranges might be acceptable, but making people define increments for integers is, in my opinion, completely not. Besides performance impact, this is a terrible user experience.</div><div><br></div><div>There are a few solutions to this:<br>1) Define ton of overrides for factory methods and specialized types for this (uhh, sounds awful)</div><div>2) Introduce new interface, say Discrete<T>, that defines T increment() (and possible T decrement()) methods. From now on, there are 2 branches:<br>2.1) Leave things as is, allow users to define incrementation logic for their types, but don't touch integers and other built-ins.I see this option as extremely inconsistent and not solving the main issue, which is iterability of integers.</div><div>2.2) Retrofit (scary) existing types to implement this interface. This should not have any compatibility nor security implications, but still sneaking into java.lang every time we need some new API to be more user-friendly is obviously not a way to go. This basically comes down to a question about how deep we want to integrate ranges into language, and is range  generalization even worth the invasion into the core of language (imo yes).</div><div>3) Leave things as they are, just let users derive iterables using something like range.asIterableWithStep(IncremetStartegy increment). I think this would make an API too narrow as no one will use it for routine tasks the same way people do in Rust, Kotlin and other languages.<br><br>I would love to hear community opinion on this matter. Which option is the most preferable, maybe some compromise between a few of them, or maybe there is a better way to go that I didn't mention here?<br><br>Best regards</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 24, 2024 at 5:11 PM Alan Snyder <<a href="mailto:javalists@cbfiddle.com" target="_blank">javalists@cbfiddle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span style="color:rgb(0,0,0)">I have another example: I have a datatype that represents a region of an audio track, for example, one tune in a medley of tunes. I allow the region to</span><div style="color:rgb(0,0,0)">specify both a start and end time, but the end time is optional (and mostly not used). When the end time is not specified, the region ends at the start of the next region, or at</div><div style="color:rgb(0,0,0)">the end of the track if there is no next region. The latter case is useful because the exact track length may not be known. The optionality of the end time</div><div style="color:rgb(0,0,0)">is not represented in the type system.</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">Having said that, I’m not sure that a general abstract interface would be useful for this example.<br id="m_-1709372893632724312m_3927220230334710857lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Sep 24, 2024, at 2:13 AM, Olexandr Rotan <<a href="mailto:rotanolexandr842@gmail.com" target="_blank">rotanolexandr842@gmail.com</a>> wrote:</div><br><div><div dir="ltr">As part of the redesigning  process , I am researching whether or not there are use cases that require asserting that the range is exactly half-bounded. This is important because I plan to switch to BoundedAtEnd/BoundedAtStart sealed interfaces instead of flags and runtime checks: Here is what I gathered for now.<br><br><ul><li><strong>Date/Time Handling (Historical or Forecast Data)</strong>: When dealing with events that started at a specific time but have no known end (e.g., open-ended employment contracts or ongoing subscriptions)</li><li><strong>Stream Processing (Real-time Event Streams)</strong>: In real-time systems, you might process data that has a start time but no defined end, such as monitoring a live video feed or logging system. The range is bounded at the start and unbounded at the end as more data will continuously arrive.</li><li><strong>Data Pagination (Fetch Until Condition)</strong>: When implementing pagination, sometimes you might want to fetch items starting from a specific index up to an unbounded limit (e.g., fetching all items after a certain point until memory runs out or a condition is met).</li><li><strong>Auditing and Monitoring</strong>: In systems where audit trails or logging data should capture all events after a certain point (bounded start) with no foreseeable end (unbounded end), such as monitoring changes to records in a database starting from a fixed timestamp.</li><li><strong>Scientific or Statistical Ranges</strong>: When modeling physical systems or statistical ranges, you might want to capture measurements that begin at a known threshold but theoretically have no upper or lower bound. For example, recording temperature data starting at absolute zero and increasing without any known upper limit.</li><li><strong>Inventory or Resource Allocation</strong>: Resource allocation policies, such as those for virtual machines, may be based on known minimum allocation thresholds but have flexible or unbounded resource caps, depending on availability.<br><br>I am writing to ask whether anyone who worked with such systems could confirm/deny that those are real use cases. If so, would it be satisfying enough to assert one-way unboundness with instanceof checks, i.e. range instanceof UnboundedEndRange && !(range instanceof UnboundedStartRange). Would appreciate any feedback.</li></ul></div></div></blockquote></div></div></div></blockquote></div>