regarding what seems (to me) unnecessary casts on integer expressions

[someone]

On Saturday, 5 June 2021 at 02:07:03 UTC, Adam D. Ruppe wrote:

> This design was a mistake.

Of all the great things I learned and read about it, this 
behavior was totally unexpected to me.

It is really difficult to code strong-typed apps this way -this 
behavior is really wonderful for writing loose scripts and the 
like and forgetting about types just to build prototypes or 
whatever, but, for really critical strong-typed apps is ... I'm 
not hurrying up to say game-over but, I can't see the way to go 
forward right now unless I am missing something.

Furthermore, if, **at least**, there was a way to clearly state 
what is short (eg 1S a la 1L) things will improve a lot, since 
any integer not having S or L could be assumed a normal integer, 
since byte has its own declaration. Writing code like:

ushort a; a = a - cast(ushort) 1; would be totally acceptable.

But writing code like:

ushort a; a = cast(ushort) a - cast(ushort) 1;

or

ushort a; a = cast(ushort)(a - 1);

would be totally silly and a waste of time I guess.

Right now I am totally immersed on Ali's book (and of course the 
tutorial and the dlang online reference) but one of the sections 
of Alexandrescu's book (have it in dead-tree-media) that I liked 
very much was the one depicting how to differentiate base types 
from one another with is flow charts.

At first sight I got the impression that any type could be 
unambiguously stated in D. Seems I was wrong.

One of the things that also immediately stuck me with D was the 
lack of proper nulls for all base types -meaning, for example for 
a string "" should not the same as null and 0 for a integer 
should not be the same as null, null (actually meaning dunno), 
and this is obviously **really useful** for database apps and a 
lot of other things.