Why does regex::Match::end return length + 1?

[hasezoey]

i have noticed that the function regex::Match::end returns the matches length + 1 and have read here that it is "idomatic", but i am not quite sure why that is, could someone maybe explain? (i know that std::ops::Range stores exclusive, but why should end do the same, when ..= exists?)

[BurntSushi]

(i know that std::ops::Range stores exclusive, but why should end do the same, when ..= exists?)

Just to nip this part in the bud, the Match API existed long before inclusive range syntax and even std::ops::RangeInclusive itself existed. So this particular aspect of the question starts from the faulty premise that ..= was even a choice at the time the regex API was stabilized.

i have noticed that the function regex::Match::end returns the matches length + 1 and have read here that it is "idomatic", but i am not quite sure why that is, could someone maybe explain?

OK so this is a great question. It's something most people don't think about and is often considered so fundamental that it's never really explicitly addressed.

The answer to your question is somewhat subtle, and it is rooted in the answer to a different question: should we use 0 or 1 to refer to the starting element of a sequence? None other than Dijkstra has opined about this. In so doing, he also answers your question:

• From Dijkstra: When using [m, n) (that is, the starting position is inclusive while the ending position is exclusive) to refer to ranges, n - m corresponds to the length of the range. If one did as you suggest and used [m, n], then the length is actually n - m + 1.
• While Dijkstra doesn't mention this, using [m, n) also permits a natural representation of an empty range. That is, [m, m) refers to a valid range at position m that is empty. If you use [m, m] to refer to a range, well, that range isn't empty, is it? So how do you represent an empty range? [m, m-1] perhaps? What about when m=0? Doesn't work. Empty ranges might seem like a silly case to consider, but the empty regex is a valid regex that matches the empty string!

Happy to answer follow-up questions. :-)

[hasezoey]

So this particular aspect of the question starts from the faulty premise that ..= was even a choice at the time the regex API was stabilized.

Didnt consider that the regex api was "older" than the range (inclusive) api, thanks for pointing this out.

---

just to clarify your syntax [,] refers to end-inclusive while [,) refers to end-exclusive?

---

thanks for you detailed comment, though i still dont quite understand why start refers to the starting character/byte of the match, but end refers to the last + 1 character/byte

[BurntSushi]

just to clarify your syntax [,] refers to end-inclusive while [,) refers to end-exclusive?

Yes. It's standard mathematical notation. [m, n] is also referred to as a "closed interval" and (m, n) is referred to an "open interval." You may also hear [m, n) (or (m, n]) referred to as a "half open" interval. See: https://stackoverflow.com/questions/4396290/what-does-this-square-bracket-and-parenthesis-bracket-notation-mean-first1-last

thanks for you detailed comment, though i still dont quite understand why start refers to the starting character/byte of the match, but end refers to the last + 1 character/byte

If you want to elaborate on what you don't understand, I'd be happy to try to fix those parts. But as it stands, it's hard to know what to clarify here. To recap briefly, the reasons are: 1) [m, n) means that the length is simply calculated by n - m which is easier to do mentally than to remember to add 1 and 2) if you used [m, n] there is no simple way of representing an empty range. I suppose a third reason is that the vast majority of all programming languages (with some notable exceptions, as Dijkstra points out) use [m, n) to refer to ranges. For example, in Python, ['a', 'b', 'c', 'd'][1:3] yields ['b', 'c'].