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.
