On Tue, Feb 13, 2024 at 06:36:22PM +0000, Nick Treleaven via Digitalmars-d-learn wrote: > On Monday, 12 February 2024 at 18:22:46 UTC, H. S. Teoh wrote: [...] > > Honestly, I think this issue is blown completely out of proportion. > > The length of stuff in any language needs to be some type. D decided > > on an unsigned type. You just learn that and adapt your code > > accordingly, end of story. Issues like these can always be argued > > both ways, and the amount of energy spent in these debates far > > outweigh the trivial workarounds in code, of which there are many > > (use std.conv.to for bounds checks, just outright cast it if you > > know what you're doing (or just foolhardy), use CheckedInt, etc.). > > And the cost of any change to the type now also far, far outweighs > > any meager benefits it may have brought. It's just not worth it, > > IMNSHO. > > I don't want the type of .length to change, that indeed would be too > disruptive. What I want is proper diagnostics like any well-regarded > C compiler when I mix/implicit convert unsigned and signed types.
I agree, mixing signed/unsigned types in the same expression ought to require a cast, and error out otherwise. Allowing them to be freely mixed, or worse, implicitly convert to each other, is just too error-prone. > Due to D's generic abilities, it's easier to make wrong assumptions > about whether some integer is signed or unsigned. But even without > that, C compilers accepted that this is a task for the compiler to > diagnose rather than humans, because it is too bug-prone for humans. Indeed. T -- Живёшь только однажды.