std.algorithm.splitter on a string not always bidirectional

[Steven Schveighoffer]

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?

> 
> Another way to look at it: If split (eager) took a predicate, that 
> 'xyz.splitter(args).back' and 'xyz.split(args).back' should produce the 
> same result. But they will not with the example given.

With what example given? The example you gave is incomplete (what are args?)

> I believe these consistency issues are the reason why the bidirectional 
> support is limited.
> 
> Note: I didn't design any of this, but I did redo the examples in the 
> documentation at one point, which is why I looked at this.

We sometimes spend time justifying why the existing implementation is 
the way it is, when we should be questioning why it was designed that 
way in the first place.

If splitter should be restricted based on possible edge cases, then it 
should be consistently restricted. My opinion is it should not be 
restricted in any case. All three cases provide equal possibility of 
bidirectional correctness. The one case that should be restricted is the 
splitter version that accepts a non-bi-directional delimiting range.

-Steve