Am Thu, 12 Jul 2012 11:30:58 -0700
schrieb Walter Bright <newshou...@digitalmars.com>:
> On 7/12/2012 2:42 AM, Marco Leise wrote:
> > I understand that some of the examples have better alternatives. What I
> > don't
> > understand is why you term this as increased language complexity. This is
> > not
> > one of the "why not add" kind of requests. From my point of view the
> > complexity is already there through U, UL, I and UI. So completing the set
> > with B, UB, S and US seems only logical and solves an existing (attention:
> > buzzword ahead) ... *inconsistency*. ;)
> >
> > To cut a long story short; if I added those suffixes and made a pull request
> > would anyone be objected?
>
> I'd object. I've been programming in C, C++ and D for 30 years now, and I use
> u
> and L suffixes way less than 1% of the time, and have simply never found a
> use
> for b or s suffixes.
>
> I'm not convinced it solves a real problem.
Alright, I'll stow it away as a little experiment. But consider, that
especially C and to some extend C++ had less cases of ambiguous data types than
D. And the point of new suffixes here is to avoid cast(byte) and cast(short) as
a means to disambiguate, namely in the cases of: method overloads using both
byte/int, array type inference and the 'auto' keyword.
C without name mangling for example wouldn't allow:
void foo(ubyte x);
void foo(int x);
foo(128);
// I'd often intuitively think, the ubyte version matches best
This is a typical case in general stream classes that offer overloaded write
methods for every supported data type, e.g.:
std.stream.EndianStream stream;
stream.write(cast(ubyte) 0x01);
// Have written 4 bytes instead of 1 in the past,
// especially when the IDE shows the first matching overload as "write(byte
x)" (Mono-D)
or with multiple constructors (here the earlier example from GtkD):
// inside the Color class
this(ubyte red, ubyte green, ubyte blue)
{
this();
set8(red, green, blue);
}
this(guint16 red, guint16 green, guint16 blue)
{
this();
set(red,green,blue);
}
// cannot call the 8-bit version without casts
_black = new Color(cast(ubyte)0,cast(ubyte)0,cast(ubyte)0);
_white = new Color(cast(ubyte)255,cast(ubyte)255,cast(ubyte)255);
An example with D's array type inference is:
void unicodeTest(char[] code) { ... }
unicodeTest("abc");
unicodeTest(cast(char[]) [cast(ubyte) 0b11000111, cast(ubyte) 0b00111111]);
// I think the second cast can be omitted here
The cases of 'auto' return or assignment can be worked around by not using auto
and may be artificial. Yet it feels like auto is partially broken, because I
cannot directly write down 8- and 16-bit integer literals like so:
auto code(...)
{
if (...) return 42us;
return 123us;
}
immutable Magic = 0x1234us;
--
Marco
