bearophile wrote:
> Stewart Gordon:
<snip>
>> If we also change array indices to be signed, it would break that
>> code that sensibly uses unsigned types, which is probably worse.
> 
> Yes, of course that code needs to be fixed after the change I have suggested. A "breaking change" means that some of the old code needs to be fixed.

That code needs to be "fixed"?  My point was that being forced to use signed types for values that cannot possibly be negative doesn't to me constitute fixing anything.

Stewart.

Stewart Gordon:
> That code needs to be "fixed"?  My point was that being forced to use signed types for values that cannot possibly be negative doesn't to me constitute fixing anything.

Yes, in my opinion it needs to be fixed. Using unsigned integers in D is a hazard, so if you use them where they are not necessary (and representing positive-only values is often not one of such cases) then you are doing something wrong, or doing premature optimization. Using a unsigned value to represent a positive-only value is not going to increase your program safety as it happens for example in Delphi, in D it decreases your program resilience.

Using size_t and uint in your code where you can use an int is something that needs to be fixed, in my opinion. Normal D programmers writing very mundane code must not be forced to face unsigned values every few lines of code. Unsigned values in D are quite bug-prone, so the language has to avoid putting them on your plate every time you want to write some code. You need to be free to use them when you want, but it's better for you to use them only when necessary.

Unsigned values have some purposes, like representing bit fields, representing very large integers (over signed values range) when you are optimizing your code and with your profiler you have found a hot spot and you want to reduce space used or increase performance, to work with bitwise operators, to work with bit fields, and few more. But letting all programmers, even D newbies mess with unsigned values every time they want to use an array length is something that will cause a very large number of bugs and wasted programming time in future D programs. You will need a hard evidence to convince me this is false.

If you want to make your D code a bit more safe you have to write code like:
cast(int)somearray_.length - degree
because if you write more normal expressions like:
somearray_.length - degree
You can quickly put some bugs in your code :-) I have written something like 300_000 lines of D code so far, and I have found a good number of unsigned-derived bugs in my code. Good luck with your code.

And by the way, in C# you have ways to use unsigned values, but I think array lengths and indexes are signed. Maybe they know better than Walter and you about this design detail.

Bye,
bearophile

bearophile wrote:
<snip>
> Yes, in my opinion it needs to be fixed.  Using unsigned integers in D is a hazard, so if you use them where they are not necessary (and representing positive-only values is often not one of such cases) then you are doing something wrong,

If it's logical and the program works, it isn't objectively wrong.  Some of us prefer to use unsigned types where the value is semantically unsigned, and know what we're doing.  So any measures to stronghold programmers against using them are going to be a nuisance.

I can also imagine promoting your mindset leading to edit wars between developers declaring an int and then putting
    assert (qwert >= 0);
in the class invariant, and those who see this and think it's brain-damaged.

<snip>
> Using size_t and uint in your code where you can use an int is something that needs to be fixed, in my opinion.  Normal D programmers writing very mundane code must not be forced to face unsigned values every few lines of code.

True, but that doesn't mean that we should force programmers to use signed values for nearly everything.

But it is all the more reason to fix unsigned op signed to be signed, if it is to be allowed at all.  The way it is at the moment, a single unsigned value in a formula can force the whole result to be unsigned, thereby leading to unexpected results.

> Unsigned values in D are quite bug-prone, so the language has to
> avoid putting them on your plate every time you want to write some
> code.  You need to be free to use them when you want, but it's better
> for you to use them only when necessary.

You could make a similar argument the same about integer types generally.  People coming from BASIC backgrounds, or new to programming generally, are sooner or later going to have some work to do when they find that 1/4 != 0.25.  Add to that the surprise that is silent overflow....

> Unsigned values have some purposes, like representing bit fields, representing very large integers (over signed values range) when you are optimizing your code and with your profiler you have found a hot spot and you want to reduce space used or increase performance, to work with bitwise operators, to work with bit fields, and few more.
<snip>

Interfacing file formats.  Simplifying certain conditional expressions.  Making code self-documenting.  Maybe others....

Stewart.