[Issue 6458] Multibyte char literals shouldn't implicitly convert to char
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Mon Aug 8 22:27:35 PDT 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6458
Don <clugdbug at yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |accepts-invalid
--- Comment #2 from Don <clugdbug at yahoo.com.au> 2011-08-08 22:27:32 PDT ---
(In reply to comment #1)
> Personally, I think that all character literals should be typed as dchar, since
> it's generally a _bad_ idea to operate on individual chars or wchars. Normally,
> the only places that chars or wchars should be used is in ranges of chars or
> wchars (which would normally be arrays). But making character literals dchar be
> default might break too much code at this point. Though, since it should be
> possible to use range propagation to verify whether a particular code point
> will fit in a particular code unit, the breakage might be minimal.
Oddly, this passes:
static assert('ä'.sizeof == 2);
So there's something a bit nonsensical about the whole thing.
> Regardless, I actually never would have expected s[0 .. 2] = 'ä' to work, since
> you're assigning a character to multiple characters as far as types go,
It's more subtle. This is block assignment.
s[0..4] = 'a'; works, and creates "aaaa".
s[0..4] = 'ä' is expected to fill the string with ä, creating "ää".
Instead, it fills it with four copies of the first uft8 byte of ä, creating an
invalid string.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list