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:

http://dlang.org/phobos/std_conv.html#.toImpl.5

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

However, as per the text under http://dlang.org/phobos/std_conv.html#.to:

"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)

-- 
Shriramana Sharma, Penguin #395953
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. #! /usr/bin/env python3 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("}") -- Shriramana Sharma, Penguin #395953
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