On Friday, 22 January 2021 at 17:29:08 UTC, Steven Schveighoffer
wrote:
On 1/22/21 11:57 AM, Jon Degenhardt wrote:
I think the idea is that if a construct like
'xyz.splitter(args)' produces a range with the sequence of
elements {"a", "bc", "def"}, then 'xyz.splitter(args).back'
should produce "def". But, if finding the split points
starting from the back results in something like {"f", "de",
"abc"} then that relationship hasn't held, and the results are
unexpected.
But that is possible with all 3 splitter variants. Why is one
allowed to be bidirectional and the others are not?
I'm not defending it, just explaining what I believe the thinking
was based on the examination I did. It wasn't just looking at the
code, there was a discussion somewhere. A forum discussion, PR
discussion, bug or code comments. Something somewhere, but I
don't remember exactly.
However, to answer your question - The relationship described is
guaranteed if the basis for the split is a single element. If the
range is a string, that's a single 'char'. If the range is
composed of integers, then a single integer. Note that if the
basis for the split is itself a range, then the relationship
described is not guaranteed.
Personally, I can see a good argument that bidirectionality
should not be supported in any of these cases, and instead force
the user to choose between eager splitting or reversing the range
via retro. For the common case of strings, the further argument
could be made that the distinction between char and dchar is
another point of inconsistency.
Regardless whether the choices made were the best choices, there
was some thinking that went into it, and it is worth
understanding the thinking when considering changes.
--Jon
