On Friday, 21 November 2014 at 15:36:02 UTC, Don wrote:
On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright
wrote:
On 11/20/2014 7:11 PM, Walter Bright wrote:
On 11/20/2014 3:25 PM, bearophile wrote:
Walter Bright:
If that is changed to a signed type, then you'll have a
same-only-different
set of subtle bugs,
This is possible. Can you show some of the bugs, we can
discuss them, and see if
they are actually worse than the current situation.
All you're doing is trading 0 crossing for 0x7FFFFFFF
crossing issues, and
pretending the problems have gone away.
BTW, granted the 0x7FFFFFFF problems exhibit the bugs less
often, but paradoxically this can make the bug worse, because
then it only gets found much, much later in supposedly tested
& robust code.
0 crossing bugs tend to show up much sooner, and often
immediately.
You're missing the point here. The problem is that people are
using 'uint' as if it were a positive integer type.
Suppose D had a type 'natint', which could hold natural
numbers in the range 0..uint.max. Sounds like 'uint', right?
People make the mistake of thinking that is what uint is. But
it is not.
How would natint behave, in the type system?
typeof (natint - natint) == int NOT natint !!!
This would of course overflow if the result is too big to fit
in an int. But the type would be correct. 1 - 2 == -1.
So if i is a natint the expression i-- would change the type of
variable i on the fly to int ?
