toInt("0b",16) != 0x0b

Oops! The trim implementation is incorrent. Need fix:

if( radix == 0 && c is '0' && len > 1 )
  switch(...)
    { ... }

if( radix == 0 )
  radix = 0;

return ...

give us a few days to think about it?

No problems.

The radix provided was intended to be a suggested one, where the content does not explicitly provide one. I think the real problem here is that "0b" is a stupid value to use as a radix indicator :)

We'll have to change the binary radix indicator to something that doesn't interfere with hex values, but I can't think of what it should be ...

I don't think that assuming radix only as suggested value is a good idea. For example:

toInt("0010", 2)

will be 10 (as a decimal value), not 2 (as a binary value).

And is it good idea to check prefix always? It tooks some time. Could it be unefficient for application with massive use of toInt?

the example would result in 2, since there's no radix descriptor on the number itself. Performance is definitely a consideration, but there's truly minor overhead involved here.

A default radix can be very useful. For example, when reading a stream of numbers like this: "10 20 30 0x10 0b0001100 0o777 15"

A default radix can be very useful. For example, when reading a stream of numbers like this: "10 20 30 0x10 0b0001100 0o777 15"

I agree. But why not to use special value for default radix? If user doesn't change radix value he allows Tango to detect the correct one. But if user specifies radix then he knows what he wants -- there is no need to do additional actions. IMHO.

I don't like changing 0b prefix to someone else, because it is almost de-facto standard for me.

You perhaps missed the point completely?

What happens in the above example where numbers are declared in a mixed manner, and the user converts using base-10? For instance, parse ("0o777", 10) ??

The explicit specification on the content must take priority, thus the provided radix is purely a default value for when an explicit radix is not present on the content itself.

BTW: I'd never seen 0b used as a prefix before, and thus conjured it up myself in a fit of bad taste :)

Replying to kris:

You perhaps missed the point completely?

No :) I suppose you missed my original proposal to change default value of radix from 10 to 0. So:

toInt( "0o777" )

means that toInt must checks prefix.

What happens in the above example where numbers are declared in a mixed manner, and the user converts using base-10? For instance, parse ("0o777", 10) ??

An exception should be here. User could use something like:

foreach( n; split("10 20 30 0x10 0b0001100 0o777 15") )
  toInt( n ); // or toInt( n, 0 );

If he use toInt(n, 10) then he made some assumptions about numbers. And if he made wrong assumtions he must get an exception.

The explicit specification on the content must take priority, thus the provided radix is purely a default value for when an explicit radix is not present on the content itself.

I just don't see reasons to explicitely specify radix argument if it is unknown which forms of number representations are used.

BTW: I'd never seen 0b used as a prefix before, and thus conjured it up myself in a fit of bad taste :)

Prefix 0b is used, at least, in two programming languages: Ruby and Curl (http://www.curl.com).

For what it's worth, I think number formats should match the language spec whenever possible. So 0x for hex, 0b for binary, etc.

The advantage of favoring the number format is that it allows processing of formatted strings. For example, a data file may be written with leading zeroes in some cases, and it should be possible to process this by explicitly telling the routine what the number format is. If the prefix is the preferred indicator, such data could easily be processed as binary, octal, and decimal, based on the encoding and whether a particular number contains leading zeroes.

(In [2526]) After extended discussions, Integer.parse() and Integer.trim() have been adjusted such that an optional radix-prefix in the text must match an explicit radix argument (where both are provided). Set the numeric radix argument to zero in order to retain prior behavior (which it defaults to).

closes #546, and thanks to eao197 for the ticket :)

So does this mean that leading zeroes must be trimmed from numbers where a radix is supplied?

no. Leading zero's are fine by themselves. If a leading zero is followed by a radix specifier, such as 0x, then that radix must match the numeric-radix provided to the function (unless the latter is zero) e.g:

convert ("10") == 10
convert ("Ox10") == 16
convert ("0x10", 16) == 16
convert ("10", 16) == 16
convert ("0x10", 10) == 0

In the latter case, the 0x prefix is not consumed (because the radix specifiers do not match) and thus the numeric parser sees 'x' as the first char. This is outside the valid range of the radix, so parsing halts and 0 is returned. Wrappers, such as toInt(), test the number of chars consumed by the parse and will throw an exception in this particular case.

Apparently, Python operates in the same manner.