length's type.

[Nick Treleaven]

On Monday, 12 February 2024 at 18:22:46 UTC, H. S. Teoh wrote:
> On Mon, Feb 12, 2024 at 05:26:25PM +0000, Nick Treleaven via 
> Digitalmars-d-learn wrote:
>> On Friday, 9 February 2024 at 15:19:32 UTC, bachmeier wrote:
>> > It's been discussed many, many times. The behavior is not 
>> > going to change - there won't even be a compiler warning. 
>> > (You'll have to check with the leadership for their reasons.)
>> 
>> Was (part of) the reason because it would disrupt existing 
>> code? If that was the blocker then editions are the solution.
>
> 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.

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.