Annoyance with new integer promotion deprecations

[Jonathan M Davis]

On Sunday, February 18, 2018 11:26:43 Manu via Digitalmars-d wrote:
> The 'solution' so add cast(int) and then cast back is not okay. I have
> code that does a lot of work on bytes/shorts (colour components are small
> integers that receive a lot of maths), and most lines get 3-4 times
> longer because of these casts...
> I can't accept that.
>
> If change the behaviour (is done), then just let the code be broken!
> Emitting these terrible noises, and encouraging people to make their code
> even noisier than the compiler output is much worse than broken code.
> There are hundreds of lines I need to molest to make the compiler shut up.
> I won't type another line of code on my colour library until this noise
> is gone... I will not maintain it. I am emotionally incapable of
> assaulting my code with those casts.

You could always create a wrapper type that does the casts for you. IIRC,
someone already discussed a solution like that in this thread in order to
make (u)byte and (u)short arithmetic more pleasant even without the recent
changes. I suspect that if you're doing a lot of arithmetic on (u)bytes or
(u)shorts, that eventually becomes pretty much the only way to maintain your
sanity - and it could be made to add runtime checks for overflow if that was
desired instead of just making the compiler shut up. Then, it could become a
runtime check instead of a blunt compile-time check if that's what's
preferred.

All in all though, this is one of those areas where trying to make it so
that C code is either valid D code with the same semantics, or it doesn't
compile gets ugly.

I suspect that the vast majority of programmers will rarely be affected by
this, because most code doesn't need to do anything with (u)bytes or
(u)shorts, but if you have a use case where you're doing a lot with them,
then I can certainly see why it would get _really_ annoying.

- Jonathan M Davis