numericValue for (unicode) characters

[Dmitry Olshansky]

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