Bug 13717 – `split` no longer defined by std.string

Just filing this so that we don't inadvertently release with a regression. This problem is caused by the import cleanups in https://github.com/D-Programming-Language/phobos/pull/2675 , specifically, commit ab83cd94dac799e9f88b4750004bc8995ff93d46.

Failing test case: ------ import std.string; void main () { foreach (s; "ab cd ef".split) {} } ------ Compiles with Phobos commit c0028b4, but fails starting with ab83cd94.

This is not regression! There is not any documentation for std.string.split. This code ------ import std.string; auto d = "ab cd ef".split; ------ compiles before only because DMD bug. We should NOT use global selective imports in druntime and phobos, until DMD bug will be fixed.

I am sorry, forget my comment. This was public imports. public import std.algorithm : startsWith, endsWith, cmp, count; public import std.array : join, split; Will be fixed

Oh, my bad... this code should be removed time ago. ------- //Remove when repeat is finally removed. They're only here as part of the //deprecation of these functions in std.string. public import std.algorithm : startsWith, endsWith, cmp, count; public import std.array : join, split; ------ What we should do with this undocumented stuff?

The `split(string)` qnd splitter variants *should* be visible from std.string. It was recently removed from std.string and moved to std.algorithm due to function/alias conflicts. These are string specific functions so at least that specific overload should be included by std.string.

What about join, startsWith, endsWith, cmp, count ?

Those probably should be included as well. That means can't get rid of those imports just yet. :-(

And we can not deprecate them too because there is now deprecation for imports ;-(

Actually, on second thoughts, does it make sense to deprecate them instead? Based on the comment, seems they're supposed to be deprecated because they got moved to other modules (std.array, std.algorithm, etc.).

Maybe we should bring this up in the forum to see if anyone has a better idea?

Also, @monarchdodra, if we're going to keep these functions in std.string, then they need to be documented, instead of being "implicitly" defined.

Here's a crazy idea: what if we introduce template wrappers for these functions, so that the import only happens if the user code actually references those symbols? For example: ----- // std.string auto split(Char1,Char2)(const(Char1) s, const(Char2) t) { import std.array : split; return split(s, t); } ----- So while we can't get rid of the dependency, at least users who don't need it, won't need to pay for it.

Please bring it to forum (my English is bad).

This is not good solution: ------ import std.array; import std.string; "foo bar".split(); //Error: much more then one template ------

typo: much -> match

Hmm, you're right. This is not good. :-( I can't think of any non-broken way to work around this problem. Looks like we'll have to put those public imports back until we can find a better solution. :-(

OK

Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/09fe0a31c60c469339cff40b537fdd724667b6ec issue 13717 https://issues.dlang.org/show_bug.cgi?id=13717 https://github.com/D-Programming-Language/phobos/commit/b049c00bbecafe220929beb947533543f02903f3 Merge pull request #2692 from 9il/issue13717 fix issue 13717

Commits pushed to 2.067 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/09fe0a31c60c469339cff40b537fdd724667b6ec issue 13717 https://github.com/D-Programming-Language/phobos/commit/b049c00bbecafe220929beb947533543f02903f3 Merge pull request #2692 from 9il/issue13717