[Issue 1357] Cannot use FFFF and FFFE in Unicode escape sequences.

[d-bugmail at puremagic.com]

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





------- Comment #16 from matti.niemenmaa+dbugzilla at iki.fi  2007-10-04 03:27 -------
(In reply to comment #15)
> (In reply to comment #14)
> >> If we're going to change this, toStringz should return a ubyte* as well.
> > 
> > There's very little chance that such a change will occur. To make it useful,
> > char (or preferably 'utf8') should implicitly cast to ubyte, or using e.g.
> > string literals would be a pain.
> 
> Only when trying to call C functions.  But even then, we wouldn't need to go as
> far as that.  Just add ubyte* to the list of types that a string literal can
> serve as.

It'd have to go beyond just string literals:

string foo = "asdf";
int i = strlen(foo.ptr);

Bad example, I know (who needs strlen?), but the above should work without
having to cast foo.ptr from char* (or invariant(char)* if that's what it is in
2.0) to ubyte*. Passing through toStringz at every call may not be an option.

> But is it really an inconsistency?  Really, all that's happened is that C's
> signed char has been renamed as byte, and C's unsigned char as ubyte.  It's no
> more inconsistent than unsigned int being renamed uint, and long long being
> renamed long.

No, not really, but Walter seems to think it important that code that looks
like C should work like it does in C. I agree with that sentiment to a point,
and thus minimizing such inconsistencies is a good idea. In this case, however,
I'd rather have the inconsistency.

> The names 'byte' and 'ubyte' better reflect how C's char types tend to be used:
> - as a code unit in an arbitrary 8-bit character encoding
> - to hold a byte-sized integer value of arbitrary semantics (though APIs that
> do this often define an alias of char to make this clearer)
> which is more or less how D programmers are using byte/ubyte, and how ISTM you
> think they should be used.

I agree.


--