Issue 5543 - conv.to should convert char to integral/floating-point as a single-char string

[ghost]

http://d.puremagic.com/issues/show_bug.cgi?id=5543

Before:

assert(to!int('1') == 49);

After:

char one = '1';
wchar two = '2';
dchar three = '3';
assert(to!int(one) == 1);
assert(to!int(two) == 2);
assert(to!int(three) == 3);
assert(to!int(to!float(one)) == 1);

Essentially char conversion would behave as if it's a string of length 1.

[monarchdodra]

Maybe add a failing conversion test?

assertThrown!ConvException(to!int('a'));

[ghost]

@monarchdodra: Good idea, thanks.

[monarchdodra]

Hum. This conversion scheme is currently a one way street.

I don't think it is acceptable to introduce char => int if we don't also introduce int => char:

    assert(to!char(9) == '9'); //Currently fails
    assert(to!char(49) == '1'); //Currently passes

Should be

    assert(to!char(9) == '9'); //Passes
    assert(to!char(49) == '1'); //Fails

[ghost]

Yeah, slipped my mind. There will still be a one-way street for char=>float though.

[monarchdodra]

There will still be a one-way street for char=>float though.

Really? Why? You'll have a tough time selling this to me if I can do this:

assert(5.0.to!int().to!char() == '5');

[ghost]

I mean to!char(1.0) does not work, but this is expected.

[DmitryOlshansky]

TBH this is a breaking change and I personally hardly find 100% clean cut to see to!int('2') to return 2 rather then ascii code.

I suppose it's more adequate to add this kind of function to std.acsii and later to std.uni (as there are other codepoints that have numeric value). In Unicode world this is called the numeric value property of a codepoint.

See e.g
http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3ANumericValue%3D1%3A%5D&g=

And certainly I don't expect floating point <--> codepoint as there is no such mapping anyway.

[jmdavis]

I don't know. I tend to think that dealing in code units is low enough level that you don't really want to encourage it with stuff like this. If the person knows what they're doing, then casting is generally fine. If they don't, then this just helps them blow their foot off. But even with dchar, as Dmitry points out, you have the problem of whether '2' is supposed to be cast(int)'2' or 2. I'm inclined to think that it's a bad idea for std.conv.to to support this. It's just too error-prone. I agree with Dmitry that it would be better for std.ascii and/or std.uni to provide stuff for this.

[ghost]

TBH this is a breaking change and I personally hardly find 100% clean cut to see to!int('2') to return 2 rather then ascii code.

char already implicitly converts to int so you wouldn't use to!int unless it's used in generic code. In that case it would be a breaking change.

Anyway, if it should be put somewhere else or rejected I don't mind.

[quickfur]

@jmdavis Yeah I agree that converting to/from ASCII (or Unicode for that matter) should be handled by std.ascii / std.uni. At the lowest level we know that char, wchar, dchar, just store the Unicode number of the character, but it's better to indicate intent in source code by using std.ascii/std.uni wrappers for cast(int)ch and (ch-'0'), etc., say codePointIdx(ch) and numericValue(ch), respectively, or something along those lines. Makes code more readable and less prone to careless slips.

[ghost]

Discussion moved here: http://d.puremagic.com/issues/show_bug.cgi?id=5543