On 06/14/2010 05:48 PM, Walter Bright wrote:
bearophile wrote:
I have found a Reddit discussion few days old:
http://www.reddit.com/r/programming/comments/cdwz5/the_perils_of_unsigned_iteration_in_cc/
It contains this, that I quote (I have no idea if it's true), plus
follow-ups:
At Google using uints of all kinds for anything other than bitmasks or
other inherently bit-y, non computable things is strongly
discouraged. This
includes things like array sizes, and the warnings for conversion of
size_t
to int are disabled. I think it's a good call.<
I have expressed similar ideas here:
http://d.puremagic.com/issues/show_bug.cgi?id=3843
Unless someone explains me why I am wrong, I will keep thinking that
using
unsigned words to represent lengths and indexes, as D does, is wrong and
unsafe, and using signed words (I think C# uses ints for that purpose)
in D
is a better design choice.
D provides powerful abstractions for iteration; it is becoming less and
less desirable to hand-build loops with for-statements.
Ooo ooo, can we remove it?
As for "unsafe", I think you need to clarify this, as D is not memory
unsafe despite the existence of integer over/under flows.
I think the problem is people don't generally think of fixnums as
fixnums when they use them.
Just recently I was reading about some security vulnerabilities in ruby
from a few years ago which were caused when whoever wrote the underlying
C didn't take integer overflow into consideration.
What I take away from this anecdote is that it's that much harder to
write trustworthy code in D. As always, the existence of issue 259
doesn't help matters.
And from personal experience, I submit that checking for overflow is
very painful to do manually (I tried to write a modular arithmetic lib
for fixnums - and gave up rather quickly). Want language support (or
library support, I don't care).
In a language as greatly numerically unsafe as D (silly C-derived
conversion
rules,
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.
fixed-sized numbers used everywhere on default, no runtime numerical
overflows) the usage of unsigned numbers can be justified inside bit
vectors,
bitwise operations, and few other similar situations only.
If D wants to be "a systems programming language. Its focus is on
combining
the power and high performance of C and C++ with the programmer
productivity
of modern languages like Ruby and Python." it must understand that
numerical
safety is one of the not secondary things that make those languages as
Ruby
and Python more productive.
I have a hard time believing that Python and Ruby are more productive
primarily because they do not have an unsigned type.
They're more productive because their built in number types aren't
fixnums. That's a nice large class of errors that don't exist in those
languages.
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/
Ruby & Python 3.0 dynamically switch to larger integer types when
overflow happens. This is completely impractical in a systems language,
and is one reason why Ruby & Python are execrably slow compared to
C-style languages.
