I have encountered two ways of doing it:

void foo(int from, int to); /* 'from' inclusive, 'to' exclusive */

void foo(int startIndex, int rangelength);

Has one style historically been preferred over the other? If so, was it just a matter of convention or was it due to some deeper underlying reason?

I'm currently programming in Java and noticed that the Arrays class uses the former style. The exclusivity of the to argument felt somewhat unintuitive to me, which led me to ask this question.

  • 1
    If you express "process items 3-5" by passing (3,5), then how would you express an empty range? Although rare, it does happen that you have to give parameters that amount to "no item", and (0, -1) would be really counterintuitive. – Kilian Foth Mar 1 '14 at 16:37
  • 1
    @KilianFoth: A range, by definition, has an upper and lower bound. Even if the bounds are the same, that's still a range of one. If having no range to process were an option, you'd either put the range in a compound structure and allow null to mean no range or skip calling foo() at all. – Blrfl Mar 1 '14 at 17:49
  • 1
    @Blrfl By whose definition? Mathematicians define two kinds of interval bounds, inclusive and exclusive; the interval (x, x) is empty for any x. And using null is hacky; does that mean "empty interval" or "Oops, I forgot to initialize this"? – Doval Jun 12 '14 at 19:11
  • 1
    The from, to convention is probably handier if you make an interval a first-class type. Operations like checking if two intervals are adjacent to each other or computing the union or intersection of two intervals would be simpler if you work with the interval boundaries. However, I agree with blrlf's answer in that "start, length" may be handier for certain kinds of APIs. But then again, you could always create a factory for an interval to do the math for you. – Doval Jun 12 '14 at 19:18
  • Which language? The answer to an API design question like this one is ALWAYS language-specific. – kevin cline Jun 12 '14 at 20:17

There isn't a hard-and-fast rule. That's because one of the fundamental tenets of API design is making your callers' lives as easy as possible by giving them an interface that takes the kinds of values they're likely to have on hand.

Your example has parallels to C's memcpy(dest, src, n) function, which copies a range of memory n bytes long starting at src to a range of n bytes long starting at dest. Most of the function's callers will be copying a primitive or data structure whose size in bytes can be determined using the sizeof operator:

some_structure src;
some_structure dest;
memcpy(&dest, &src, sizeof dest);  // Easy to understand

Had the function been implemented as memcpy(dest, src_start, src_end) (where src_start and src_end are pointers to the first and last bytes in the structure, the caller would have to do a lot more gymnastics to figure out where the source structure ends:

memcpy(&dest, &src, ((void *)&src) + sizeof src - 1);  // Harder to understand

What doesn't work well for memcpy() might work very well for functions that do counting. If you know your callers have upper and lower range bounds in hand, it's much better to give them count(int from, int to) than count(int start, int how_many):

int lower;
int upper;
count(lower, upper);  // No gymnastics


count(lower, upper-lower+1);  // Gymnastics

Even if the innards of count() need to know the number of iterations, it's better to calculate it in one place (inside the function) than force your callers who have upper and lower bounds to calculate it every time.

Sometimes which is better may be a toss-up. In those cases, you provide two functions, one that does the grunt work and another that's just a wrapper that does the additional calculation:

count_iters(int start, int iterations) {
    // Do whatever this function does

count_range(int lower, int upper) {
    count_iters(lower, upper-lower+1);

Providing the wrapper centralizes the calculation of the number of iterations, which means that fixing a bug in it will correct the problem for everything at once and you won't have to find and change every caller that's doing it wrong.

Bottom line: If you pick one or the other arbitrarily or because someone says one style is better than the other, you haven't examined the use cases and made a decision.

  • +1 for an awesome (correct) answer to a trivial (controversial) question – Mahdi Jun 13 '14 at 5:32

Which language? The answer to API design questions like this one is always language-specific. Many languages have built-in support for ranges. In those languages the answer is easy: use a single argument of whatever type is used to represent a range.

For Java, you might consider com.google.common.collect.Range from Google's Guava library.

While exclusive upper bounds may seem unnatural, they are far more convenient than inclusive ranges because they eliminate a lot of fiddling around adding and subtracting one. Inclusive ranges over continuous types like time are very troublesome. How often have you seen things like { start: 00:00, end: 23:59 } ? What about 23:59:30 ? Using exclusive ranges eliminates those questions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy