1/3/2013 2:15 AM, monarch_dodra пишет:
On Wednesday, 2 January 2013 at 20:49:38 UTC, Dmitry Olshansky wrote:
Yup, and it's 2 lines then. And if one really wants to chain it:
map(a => enforce(std.ascii.isNumeric(a)), a -= '0')(...);
Hardly makes it Phobos candidate then ;)
Well, just because its almost trivial to us doesn't mean it hurts to
have it. The fact that you can even operate on chars in such a fashion
(c - '0') is not obvious to everyone: I've seen time and time again code
such as:
//----
if (97 <= c && c <= 122)
c -= 97;
//----
numericValue helps keep things clean and self documented.
What's more, it helps keep ascii complete. Code originally written for
ascii is easily upgreable to support uni (and vice-versa). Further more,
*writing* "std.ascii.numericValue" self documents ascii only support,
which is less obvious than code using "c - '0'":
In the original pull request to "improve" conv.to, the fact that it did
not support unicode didn't even cross our minds. Seeing
"std.ascii.numericValue" raises the eyebrow. It *forces* unicode
consideration (regardless of which is right, it can't be ignored).
Really, by the rationale of "it's 2 lines", we shouldn't even have
"std.ascii.isNumeric" at all...
I don't mind adding because of completeness and/or symmetry stand point
as I said.
I do see another cool issue popping up though. It's a problem of how the
anti-hijacking works. Say we add numericValue right now to std.ascii but
not std.uni. A release later we have numericValue in std.uni (well
hopefully they are both in the same 2.062 ;) ).
Now take this code:
map!numericValue(...)
If the code also happens to import std.uni it's going to stop compiling.
That's one of reasons I think our hopes on stability (as in compiles in
5 years from now) are ill placed as we can't have it until the library
is essentially dead in stone.
--
Dmitry Olshansky
