[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