I ran into a Rosetta code solution in D that had obvious errors.
It's like the author or the previous editor wasn't even trying to
do it right, like a protest against how many detailed rules the
task had. I assumed that's not the way we want to do things in D.
Then I spent all day fixing it. Once I thought I had it working,
I added some unittests, and realized it wasn't really correct,
and struggled with the more complicated regex I had written,
until it was simplified, and I really fixed it. So I pushed it,
hard.
The earlier version of the page made D look more error prone than
other languages, but short. Now my solution is as long as some of
the other language's solutions, but it's well commented and
tested, I think. Now I doubt any of the solutions in other
languages are as correct or potentially useful or informative.
Something I removed was there was a commented out /* pure nothrow
*/ someone had left there, and a @safe attribute, because those
don't work with using the parts of the library that I used. It
seems like there's a tangle of features in the library that would
take a lot more usage examples than what can fit in the library
doc itself to sort out for people.
Is it normal to add a bunch of wished-for future attributes to a
function, then comment them out because they don't compile yet?
Maybe that's something that happens often with D code, but I
didn't think that should be how D is advertised.
An extra that I could add, if I should push again, is using the
compile time regex function ctRegex, but I found out that's not
enough to make the function nothrow, by far.
Does anyone have any thoughts about this? Did I do right by D?
http://rosettacode.org/wiki/Commatizing_numbers
