length's type.

[H. S. Teoh]

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

-- 
Живёшь только однажды.