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
