Issue 10772 - std.regex.splitter generates spurious empty elements with empty delimiter
Summary: std.regex.splitter generates spurious empty elements with empty delimiter
Status: NEW
Alias: None
Product: D
Classification: Unclassified
Component: phobos (show other issues)
Version: D2
Hardware: All All
: P3 normal
Assignee: Dmitry Olshansky
URL:
Keywords: pull
Depends on:
Blocks:
 
Reported: 2013-08-07 12:54 UTC by hsteoh
Modified: 2024-12-01 16:18 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description hsteoh 2013-08-07 12:54:11 UTC
CODE:
--------
void main() {
    import std.string, std.stdio, std.regex;
    string s = "test";
    writeln(std.regex.splitter(s.toUpper, regex("")));
}
--------

Output:
--------
["", "T", "E", "S", "T", ""]
--------

The first and last empty elements should not be included in the result. Cf. Perl's split(//, "test").
Comment 1 Dmitry Olshansky 2013-12-18 13:10:33 UTC
(In reply to comment #0)
> CODE:
> --------
> void main() {
>     import std.string, std.stdio, std.regex;
>     string s = "test";
>     writeln(std.regex.splitter(s.toUpper, regex("")));
> }
> --------
> 
> Output:
> --------
> ["", "T", "E", "S", "T", ""]
> --------
> 
> The first and last empty elements should not be included in the result. Cf.
> Perl's split(//, "test").

The matter is more or less trivial, the only problem is what you actually want me to do?

No matter how I read this passage:
http://perldoc.perl.org/functions/split.html
I can only gather that 0-width match at front of input is never produced (okay..). What the heck must be happening with the one at the end isn't clear to me at all.

Given that the following test produces ["T", "E", "S", "T"] we may just ignore 0-width match at both ends to be in line. The behaviour needs to be documented though. Anyway - seems good?
 
void main() {
    import std.string, std.algorithm, std.stdio;//, std.regex;
    string s = "test";
    writeln(splitter(s.toUpper, ""));
}
Comment 2 hsteoh 2013-12-18 14:28:29 UTC
$ perl -e'print join(":", split(//, "test")), "\n";'
t:e:s:t
$


So yes, I expect std.regex.splitter to return ["t", "e", "s", "t"] when the delimiter is empty.
Comment 3 Dmitry Olshansky 2013-12-19 08:51:38 UTC
(In reply to comment #2)
> $ perl -e'print join(":", split(//, "test")), "\n";'
> t:e:s:t
> $
> 
> 
> So yes, I expect std.regex.splitter to return ["t", "e", "s", "t"] when the
> delimiter is empty.

But then there is this:
perl -e'print join(":", split(/, /, ", test, ")), "\n";'
:test

That makes no sense to me whatsoever.

We have tests already (always had, even before 2.056) that state the opposite.
In fact they make sure that both zero-width pieces are found (at start and at end).
Comment 4 Dmitry Olshansky 2013-12-19 10:11:20 UTC
https://github.com/D-Programming-Language/phobos/pull/1790

My compromise is to follow std.algorithm splitter and special case 0-width matches as if 0-width needles.
Comment 5 monarchdodra 2013-12-19 10:18:12 UTC
Arguably, 0-width splitting makes no sense: If it were to rigorously follow the rules, then you'd simply end up with an infinite amount of leading tokens.
["", "T", "E", "S", "T", ""]
Makes no sense to me. Why is there an empty leading/trailing token, but none between each letter?

This means that in regards to 0-length splitting, it should either be an *error*, or have a *special behavior*

std.algorithm.split simply special cases to do what seems most useful (what is documented by pearl, AFAIK). I think having regex do the same is most sensible.
Comment 6 monarchdodra 2013-12-19 10:22:46 UTC
(In reply to comment #5)
> Arguably, 0-width splitting makes no sense: If it were to rigorously follow the
> rules, then you'd simply end up with an infinite amount of leading tokens.
> ["", "T", "E", "S", "T", ""]
> Makes no sense to me. Why is there an empty leading/trailing token, but none
> between each letter?
> 
> This means that in regards to 0-length splitting, it should either be an
> *error*, or have a *special behavior*
> 
> std.algorithm.split simply special cases to do what seems most useful (what is
> documented by pearl, AFAIK). I think having regex do the same is most sensible.

Hum... Actually, now that I think about it, algorithm splitter works on constant length separator. I'm not sure how you'd handle a separator that may and or may not be empty...

See the examples in your pull.
Comment 7 Dmitry Olshansky 2013-12-19 10:48:49 UTC
(In reply to comment #5)
> Arguably, 0-width splitting makes no sense: If it were to rigorously follow the
> rules, then you'd simply end up with an infinite amount of leading tokens.
> ["", "T", "E", "S", "T", ""]
> Makes no sense to me. Why is there an empty leading/trailing token, but none
> between each letter?
> 
> This means that in regards to 0-length splitting, it should either be an
> *error*, or have a *special behavior*

There is already special case that 0-width regular expression match advances input by one codepoint. It's exactly this special case that produces the string above, nothing to worry about.

> 
> std.algorithm.split simply special cases to do what seems most useful (what is
> documented by pearl, AFAIK). I think having regex do the same is most sensible.

Doing special-special case is kind of bad. The more I look at this the more it's clear to me that we either have to decipher Perl's behaviour or give up.
Comment 8 dlangBugzillaToGithub 2024-12-01 16:18:34 UTC
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/phobos/issues/9997

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB