Signed word lengths and indexes

[Walter Bright]

bearophile wrote:
> Walter Bright:
>> As for "unsafe", I think you need to clarify this, as D is not memory
>> unsafe despite the existence of integer over/under flows.<
> 
> Modern languages must understand that there are other forms of safety beside
> memory safety. Integer overflows and signed-unsigned conversion-derived bugs
> can cause disasters as well.
> 
> In current D language the usage of unsigned numbers is a safety hazard. So
> far nothing I have seen written by you or other people has shown that this is
> false.

D's safe mode, integer overflow *cannot* lead to memory corruption. So when you 
say something is "unsafe", I think it's reasonable to ask what you mean by it.

For example, if you define "safe" as "guaranteed to not have bugs", then you're 
requiring that there be a proof of correctness for all programs in D.


>> Actually, I think they make a lot of sense, and D's improvement on them
>> that only disallows conversions that lose bits based on range propagation
>> is far more sensible than C#'s overzealous restrictions.<
> 
> 1) I'd like D to use signed words to represent lengths and array indexes.

This would lead to silent breakage of code transferred from C and C++. We've 
tried very hard to not have such things in D. The idea is that code that looks 
the same either behaves the same or issues an error. There's no way to make your 
proposal pass this requirement.


> We are going to 64 bit systems where 63 bits can be enough for lenghts. If
> arrays of 4 billion items are seen as important on 32 bit systems too, then
> use a long :-) 2) I don't like D to silently gulp down expressions that mix
> signed and unsigned integers and spit out wrong results when the integers
> were negative.

That idea has a lot of merit for 64 bit systems. But there are two problems with it:

1. D source code is supposed to be portable between 32 and 64 bit systems. This 
would fail miserably if the sign of things silently change in the process.

2. For an operating system kernel's memory management logic, it still would make 
sense to represent the address space as a flat range from 0..n, not one that's 
split in the middle, half of which is accessed with negative offsets. D is 
supposed to support OS development.



>> I have a hard time believing that Python and Ruby are more productive
>> primarily because they do not have an unsigned type.<
> 
> Python is very productive (for small or medium sized programs! On large
> programs Python is less good) because of a quite long list of factors. My
> experience with D and Python (and several other languages) has shown me that
> Python not using fixnums is one of the factors that help productivity. It's
> surely not the only factor, and I agree with you that it's not the most
> important, but it's surely one of the significant factors and it can't be
> ignored.

We can argue forever with how significant it is, I don't assign nearly as much 
to it as you do.


> Python integers don't overflow,
> this at the same time allows you to safe
> brain time and brain power thinking about possible overflows and the code to
> avoid their risk, and makes coding more relaxed. And if you try to write 50
> Project Euler programs in Python and D you will surely see how many bugs the
> Python code has avoided you compared to D. Finding and fixing such bugs in D
> code requires lot of time that you save in Python.

This is where we differ. I very rarely have a bug due to overflow or 
signed/unsigned differences. If you use the D loop abstractions, you should 
never have these issues with it.


>> Python did not add overflow protection until 3.0, so it's very hard to say 
>> this crippled productivity in early versions.
>> http://www.python.org/dev/peps/pep-0237/
> 
> You are wrong. Python 2.x dynamically switches to larger integer types when
> overflow happens. This is done transparently and avoids bugs and keeps
> programs more efficient. This is on Python V.2.6.5 but similar things happen
> in much older versions of Python:
> 
>>>> a = 2 type(a)
> <type 'int'>
>>>> a += 10 ** 1000 len(str(a))
> 1001
>>>> type(a)
> <type 'long'>

Here's what the wikipedia said about it.

"In Python, a number that becomes too large for an integer seamlessly becomes a 
long.[1] And in Python 3.0, integers and arbitrary sized longs are unified."

-- http://en.wikipedia.org/wiki/Integer_overflow

(Just switching to long isn't good enough - what happens when long overflows? I 
generally don't like solution like this because it makes tripping the bug so 
rare that it can lurk for years. I prefer to flush bugs out in the open early.)


>> This is completely impractical in a systems language, and is one reason why
>> Ruby & Python are execrably slow compared to C-style languages.
> 
> Lisp languages can be only a 1.0-3.0 times slower can C despite using mostly
> multi-precision numbers. So I don't think well implemented multi-precision
> numbers are so bad in a very fast language.

3x is a BIG deal. If you're running a major site, this means you only need 1/3 
of the hardware, and 1/3 of the electric bill. If you're running a program that 
takes all day, now you can run it 3 times that day.