splitter for strings

[Chris via Digitalmars-d-learn]

On Monday, 9 June 2014 at 18:09:07 UTC, monarch_dodra wrote:
> On Monday, 9 June 2014 at 17:57:24 UTC, Steven Schveighoffer 
> wrote:
>> I think we are confusing things here, I was talking about 
>> strip :)
>
> strip and split are actually both pretty much in the same boat 
> actually in regards to that, so just 's/split/strip/g', and the 
> same answer will apply.
>
> "split" (and "splitter") actually have it a bit more 
> complicated, because historically, if you imported both string 
> and algorithm, then "split(myString)" will create an ambiguous 
> call. The issue is that you can't do selective imports when you 
> already have a local object with the same name, so algorithm 
> had:
>
> ----
> auto split(String)(String myString) {
>    return std.string.split(myString);
> }
> ----
> rather than
> ----
> public import std.string : split;
> ----
>
> I tried to "fix" the issue by removing "split(String)" from 
> algorithm, but that created some breakage.
>
> So Andrei just came down and put *everything* in algorithm, and 
> added an "public import std.algorithm : split" in std.string.
>
> This works, but it does mean that:
> 1. string unconditionally pulls algorithm.
> 2. You can do things like:
>    std.string.split([1, 2, 3], 2);
>
> IMO, the "strip" solution is better :/
>
>> If we could split up std.algorithm into individual modules, 
>> that would probably help.
>>
>> -Steve
>
> Yes.

I think it makes sense to put any generic range based algorithms 
(split and so forth) into std.algorithm. It's always my first 
port of call, when I have a range. However, that you can do

std.string.split([1, 2, 3], 2);

is not exactly a desirable situation.