std.algorithm.splitter on a string not always bidirectional

[Jon Degenhardt]

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