On Thu, 15 May 2014 11:37:07 -0400, monarch_dodra <monarchdo...@gmail.com>
wrote:
On Thursday, 15 May 2014 at 13:26:45 UTC, Steven Schveighoffer
wrote:
On Wed, 14 May 2014 05:13:42 -0400, Jonathan M Davis via
Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
On Wed, 14 May 2014 08:27:45 +0000
monarch_dodra via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:
As a matter of fact, the built in "sort" property does it.
void main()
{
char[] s = "éöeèûà".dup;
s.sort;
writeln(s);
}
//prints:
eàèéöû
I'm surprised. I thought that one of Bearophile's favorite complaints
was that
it didn't sort unicode properly (and hence one of the reasons that it
should
be removed). Regardless, I do think that it should be removed.
I can't believe this worked. I want to say that it's a freak accident
for that set of characters. Looking in druntime, I don't see where the
special case is.
-Steve
Must be a hell of a freak accident ;)
auto s = "é東öe京ûタèワà".dup;
writeln(s.sort);
=> eàèéöûタワ京東
It's in rt/adi.d
Seriously, I fucking hate the file names in druntime.
I looked in qsort.d.
extern (C) char[] _adSortChar(char[] a)
It's basically: string=>dstring=>sort=>dstring=>string.
OK, that's what I would have expected. I don't think we should support
this.
BTW, the built in reverse also works with char[], and so does
std.algorithm.reverse (and it does it pretty cleverly too, might I say).
This is a different algorithm. Sort requires random-access swapping.
Reverse does not.
As far as I'm concerned, if we *can* do it in n.log(n), and somebody
provides the implementation, then there is no reason to not offer dchar
sorting for char[]/wchar.
I think there is nothing wrong with requiring the steps to be explicit. We
should not hide such bloat behind sort.
-Steve
