The "isTerminator" version of std.algorithm.splitter, eg:
auto splitter(alias isTerminator, Range)(Range input)

Returns an object that is "only" ForwardRange. This is especially weird, since the normal "separator" version is bidirectional. Comparing using a function rather than with a value should have no difference...

This defect "leaks" into std.array.splitter, defined as:

auto splitter(C)(C[] s)
    if(isSomeString!(C[]))
{
    return std.algorithm.splitter!(std.uni.isWhite)(s);
}

Here is some code reproducing it:

----
import std.array;
import std.algorithm;
import std.stdio;

void main()
{
  string s = "  hi!  my name is Monarch  ";
  auto words = std.array.splitter(s);
  if(words.front == "") words.popFront();
  if(words.back == "") words.popBack(); //What???
  foreach(word; words)
    writeln(word);
}
----

Kind regards,
Monarch Dodra

On 6/30/12 7:21 AM, monarch_dodra wrote:
> The "isTerminator" version of std.algorithm.splitter, eg:
> auto splitter(alias isTerminator, Range)(Range input)
>
> Returns an object that is "only" ForwardRange. This is especially weird,
> since the normal "separator" version is bidirectional. Comparing using a
> function rather than with a value should have no difference...

I think that may as well be an oversight in the implementation of splitter.

Andrei

On Saturday, 30 June 2012 at 14:01:08 UTC, Andrei Alexandrescu wrote:
> On 6/30/12 7:21 AM, monarch_dodra wrote:
>> The "isTerminator" version of std.algorithm.splitter, eg:
>> auto splitter(alias isTerminator, Range)(Range input)
>>
>> Returns an object that is "only" ForwardRange. This is especially weird,
>> since the normal "separator" version is bidirectional. Comparing using a
>> function rather than with a value should have no difference...
>
> I think that may as well be an oversight in the implementation of splitter.
>
> Andrei

Hi Andrei, thanks for the answer.

I would have thought as well. however, upon inspection, it would appear the algorithm uses std.range.take, which does not allow support for bidirectional ranges. I started another thread about it here:
http://forum.dlang.org/thread/pzudyijsfcpwlqermwke@forum.dlang.org

This looks to me like a language (range) defect. I would love to hear your thoughts on it.

Kind Regards,
Paul