downs wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
Andrei Alexandrescu:
Splitter does what Perl's split does: 2.
Perl has to die. This is Python:
This answer is wrong for a number of reasons. First comes the fallacy
that if Perl "has to die", everything Perl did was wrong. Second comes
the fallacy that if Python is overall better than Perl, everything it
does is better than everything Perl does.
",a,b,".split(",")
['', 'a', 'b', '']
My lazy xsplit too works like that. I strongly vote for (4).
Why? I'd be willing to change things no problem, but "perl must die,
here's python" just doesn't seem to have much persuasive power.
Andrei
It is my strong opinion that Perl did this wrong. Why? Because it quite
strongly violates user expectations.
Please keep magic out of D as far as possible. If unavoidable, mark it with big
warning signs. Magic is the *enemy* of comprehension.
Microsoft once experimented with tools that tried to predict what you wanted
instead of what you _said_.
The result was *Clippy*. I don't need to tell you how that went.
FWIW: If I wanted to remove trailing spaces, I'd use the well-known .strip()
function.
I have been convinced. I will modify splitter to do (4), i.e., prepend
or append an empty element if there's a leading, respectively trailing,
separator. Thanks to all for destroying me :o).
Actually, Brad, since it was your idea, I suggest you to operate the
change and add yourself to the list of contributors to std.algorithm.
I have constructed an information-theory-based argument that was alluded
to by some posters without being clearly stated: if splitter does (4)
and the separator is a character or a string, then you can reconstruct
the original input from its output. So (4) is the behavior that loses
the least information. (Brad was on a similar track by stating that it's
desirable for splitter to produce the same number of items whether ran
forward or in reverse.)
Andrei
