www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - to(T, ubyte base) if (isIntegral!T)

reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Hello. I thought D did not prove the Python facility of being able to handle 
bases 2 to 36 in string to integer conversion on request (there it is 
int(num, base = )), but came upon this toImpl overload:



which provides for a radix to be input. There's also a corresponding parse 
overload.



"Entry point that dispatches to the appropriate conversion primitive. Client 
code normally calls to!TargetType(value) (and not some variant of toImpl)."

... I'm not sure why the toImpl and parse functions are even publicly 
documented. People shouldn't need to know about them.

So given that toImpl is supposed to be internal, shouldn't we have a to! 
function for specifying the base, something like:

T to(T, ubyte base) if (isIntegral!T && 2 <= base && base <= 36)

--
Oct 17 2015
next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Saturday, 17 October 2015 at 11:27:39 UTC, Shriramana Sharma 
wrote:

 So given that toImpl is supposed to be internal, shouldn't we 
 have a to! function for specifying the base, something like:

 T to(T, ubyte base) if (isIntegral!T && 2 <= base && base <= 36)


It is actually available:

void main() {
     import std.conv;
     assert("1f".to!int(16) == 31);
}

I doesn't appear in the documentation explicitly, but `to` just 
forwards all of its arguments to `toImpl`. I agree that the 
documentation of the `to`-family should be consolidated.
Oct 17 2015
parent Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Marc Schütz wrote:


 void main() {
 import std.conv;
 assert("1f".to!int(16) == 31);
 }


Hey thanks. In case the library maintainer wants to tighten up the unittest 
for this, I wrote up a short Python to produce a unittest for this, since 
Python also has the same support.


from random import choice
digitsH = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"
digitsL = digitsH.lower()
digits = (digitsH, digitsL)
print("""\
import std.conv;
unittest
{\
""")
for base in range(2, 37):
    for i in range(8):
        s = "".join(choice(choice(digits)[:base]) for j in range(8))
        v = int(s, base)
        print('    assert("{}".to!ulong({:>2}) == {:>20});'.format(s, base, 
v))
print("}")

--
Oct 17 2015
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, 17 October 2015 at 11:27:39 UTC, Shriramana Sharma 
wrote:

 ... I'm not sure why the toImpl and parse functions are even 
 publicly documented. People shouldn't need to know about them.


As the documentation briefly explains on std.conv.to, all of the 
overloads of to are toImpl, and we obviously need to document the 
overloads (particularly considering how diverse they are), so you 
unfortunately end up with toImpl in the documentation even though 
it's essentially an implementation detail. All you have to do is 
use to every time you see toImpl.

Obviously, that's not exactly ideal, but I suspect that at the 
time that std.conv.to was created, there wasn't much choice. 
std.conv.to has been around for quite a while, and eponymous 
templates have improved quite a bit since then. It should be 
possible now for all of the toImpl overloads to be moved inside 
of std.conv.to and have them all be called std.conv.to, but I'm 
not sure that that was possible when std.conv.to was introduced.

However, unless something like DIP 82 is implmented ( 
http://wiki.dlang.org/DIP82 ), it would actually be pretty 
problematic to move all of those overloads inside of the the main 
to template, because it would either mean putting all of those 
unittest blocks inside of that template (very bad idea) or 
separating each of the unittest blocks from the overloads that 
they're testing (also a very bad idea). So, at least for now, it 
just makes more sense to have toImpl. And if it confused you, 
then sorry, but the documentation does at least try to make it 
clear, and all of the examples use to, not toImpl. At least now 
that you know, it really shouldn't be a problem reading those 
docs anymore.

- Jonathan M Davis
Oct 17 2015