On 7/4/11 4:40 PM, bearophile wrote:
Andrei:
unsafe(overflows) { // code here }
This approach has a number of issues.
This approach is the one used by Delphi, Ada and C# (C# has a way to
specify even inside a single expression), so somehow it's doable.
I didn't say it wasn't doable. There, you're _quoting_ my answer: "This
approach has a number of issues."
Second, programmers are notoriously bad at choosing which code is
affecting bottom line performance, yet this feature explicitly puts
the burden on the coder. So code will be littered with amends, yet
still be overall slower. This feature has very poor scalability.<
You are looking at it from the wrong point of view.
There we go with "wrong" again.
The
overflow-safety of the code is not about performance, it's about
safety, that is about the level of safety you accept in a part of the
code.
Isn't it about the way you define safety, too?
It's about trust. If you can't accept (trust) a piece of code
to be overflow-unsafe, then you can't accept it, regardless the
amount of performance you desire.
This makes no sense. How about trusting or not a piece of code that has
possible bugs in it? That's unverifiable and unfalsifiable. That's why
the notion of "memory safety" carries weight: no matter what it does, a
memory-safe module cannot compromise the integrity of the type system.
That _is_ about trust, not integral overflow.
Of course they're not the same thing. Commonalities and
differences.
I meant that safety is not the same thing as shifting the definition
of a range. Overflow tests are not going to produce isomorphic code.
And I meant that either choice could go either way, that reasonable
people may disagree about what the choice should be, and that D will not
adopt either in the foreseeable future.
Well they also are a solid way to slow down all code.
The slowdown doesn't touch floating point numbers, some Phobos
libraries that contain trusted code, memory accesses, disk and net
accesses, it doesn't influence GUI code a lot, and in practice it's
usually acceptable to me, especially while I am developing/debugging
code.
I think you are underestimating the impact of the change. Enumerating
parts that won't be affected doesn't make the affected parts less frequent.
You are using a different version of safety than D does. D defines
very precisely safety as memory safety. Your definition is larger,
less precise, and more ad-hoc.<
D has @safe that is about memory safety. But in D there is more than
just @safe, the D Zen is about the whole D language, and in D there
are many features that help to make it safer beyond memory safety.
I'm sure you know more about the D Zen than most people, but it's not
impossible that automatic overflow checking is not a part of it.
Probably one good thing to get past is the attitude that in such a
discussion the other is "wrong".<
In a recent answer I have tried to explain why you can't implement
compile-time overflows in library code:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=139950
Here I am right or wrong, it's not a matter of POV.
I'm afraid it is, as your argument is rife with just debatable
statements, and is generally surprising weak compared with the zeal with
with you're quoting it. Perhaps I fail to get the gist of your
statements, so allow me:
"There are routines for run-time overflow tests in C and C++, but I am
not seeing them used." -> subjective. It all says you're frequenting
other circles than other people.
"While in Delphi I use overflow tests all the time and I see code
written by other people that have runtime overflow tests switched on."
-> subjective, relates what you do and see.
"I think that to catch integral overflow bugs in programs you can't just
add a SafeInt struct, you need a compiler-wide switch. Otherwise most
people will not use it." -> subjective and unsubstantiated. Also, if
people don't use SafeInts that frequently may actually be because it's
not a problem at the top of their list. I mean how can you draw that
conclusion from that hypothesis?
"Array bound tests are able to catch bugs in normal D code written by
everybody because you don't need to use a SafeArray instead of the built
in arrays and because array bound tests are active on default, you need
a switch to disable them. A bit more syntax is needed to disable tests
locally, where needed." -> array bounds checking is a _vital_ feature
for safe code, not an option.
I don't see how all of this makes you feel you're in possession of a
bulletproof case, and the remaining issue is to make sure the others
understand and internalize it.
I have also explained that taking an arbitrary D code written by you
and replacing all instances of int and uint with safeInt and safeUint
is not going to happen. It's like array bounds in D code. If you need
to add a safeArray type to spot all array bound overflows, then it's
a lost cause, people are not going to do it (well, the case with a
safeArray is better, because I am using a safe array in C++).
I think there is a bit of confusion between "explaining" and "exposing
one's viewpoint".
These are simple matters of which understanding does not require
any amount of special talent or competence.<
Right, but several people don't have experience with using languages
with integral overflows, so while their intelligence is plenty to
understand what those tests do, they don't have the experience about
the bugs they avoid and the slowdown they cause in practice in tens
of practical situations. Some ratical experience about a feature is
quite important when you want to judge it, I have seen it many times,
with dynamic typing, good tuples, array bound tests, pure functions,
and so on, so I suspect the same happens with integral overflows.
So the first step is to understand that some may actually value a
different choice with different consequences than yours because
they find the costs unacceptable.<
I am here to explain the base of my values :-) I have tried to use
rational arguments where possible.
I think there's a fair amount of contradiction in said values. People on
this forum have noticed that you sometimes directly contradict your own
posts. Which is fine as long as there's understanding that
over-insistence in any particular direction may hurt good language design.
As someone who makes numerous posts and bug reports regarding speed
of D code, you should definitely have more appreciation for that
view.<
I'm not a one trick pony, I am a bit more flexible than you think :-)
In this case I think that fast but wrong/buggy programs are useless.
Correctness comes first, speed second. I think D design goals agree
with this view of mine :-)
Then it should come as a surprise to you that Walter disagrees. There's
a bit of cognitive dissonance there, isn't there? How do you assuage it?
Andrei
