splitter string/char different behavior

[Jonathan M Davis]

On Saturday, September 30, 2017 20:18:25 Jon Degenhardt via Digitalmars-d-
learn wrote:
> On Saturday, 30 September 2017 at 17:17:17 UTC, SrMordred wrote:
> > writeln( "a.b.c".splitter('.').dropBack(1) ); //compiles ok
> > writeln( "a.b.c".splitter(".").dropBack(1) );
> >
> > //error:
> > Error: template std.range.dropBack cannot deduce function from
> > argument types !()(Result, int), candidates are:
> > (...)
> >
> > Hm.. can someone explain whats going on?
>
> Let's try again. I'm not sure the full explanation, but likely
> involves two separate template overloads being instantiated, each
> with a separate definition of the return type.
>
> * "a.b.c".splitter('.') - This overload:
> https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L369
> 6-L3703
>
> * "a.b.c".splitter(".") - This overload:
> https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L397
> 3-L3982
>
> But why one supports dropBack and the other doesn't I don't know.

Well, figuring out where to split when iterating in reverse is trivial when
splitting on a single element, but it's not when dealing with a range of
elements. Sure, in this case, because the range happens to be only one
character long, it would be easy, but as soon as it has multiple characters,
it wouldn't be - especially if you got nonsense like

auto result = "ttttttttttttt".splitter("ttt");

In order to know where to split, it really has to do it from the front. If
it starts from the back, you won't necessarily split in the same places as
when iterating from the front, and that would violate how bidirectional
ranges are supposed to work (the elements should be the same - just in
reverse - if you iterate from the back). That being the case, it makes sense
that splitting on a single element would result in a range that was
bidirectional, whereas splitting on a range of elements would result in a
range that's only a forward range.

- Jonathan M Davis