On Wednesday, 31 May 2017 at 23:51:30 UTC, Jonathan M Davis wrote:
On Wednesday, May 31, 2017 23:13:35 Moritz Maxeiner via
Digitalmars-d wrote:
On Wednesday, 31 May 2017 at 22:47:38 UTC, Steven
Schveighoffer wrote:
> Again, there has not been memory corruption.
Again, the runtime *cannot* know that and hence you *cannot*
claim that. It sees an index out of bounds and it *cannot*
reason about whether a memory corruption has already occurred
or not, which means it *must assume* the worst case (it must
*assume* there was).
Honestly, once a memory corruption has occurred, all bets are
off anyway.
Right, and that is why termination when in doubt (and the
programmer has not done anything to clear that doubt up) is the
sane choice.
The core thing here is that the contract of indexing arrays was
violated, which is a bug.
I disagree about it being the core issue, because that was
already established in the OP.
If we're going to argue about whether it makes sense to change
that contract, then we have to discuss the consequences of
doing so, and I really don't see why whether a memory
corruption has occurred previously is relevant.
Because if such a memory corruption occurred, termination of the
closest enclosing scope to get rid of it must follow (or your
entire system can end up corrupted).
We could easily treat indexing arrays the same as as any other
function which chooses to throw an Exception when it's given
bad input. The core difference is whether it's considered okay
to give bad values or whether it's considered a programming bug
to pass bad values. In either case, the runtime has no way of
determining the reason for the failure, and I don't see why
passing a bad value to index an array is any more indicative of
a memory corruption than passing an invalid day of the month to
std.datetime's Date when constructing it is indicative of a
memory corruption. In both cases, the input is bad, and the
runtime doesn't know why.
One of those is a library construct, the other is baked into the
language; it is perfectly fine for the former to use exceptions,
because it can be easily avoided by anyone; the latter is a
required component of pretty much everything you can build with D
and must thus use the stricter contract.
The issue ultimately is what the consequences are of using an
Error vs an Exception, and _that_ is what we need to discuss.
An Exception leads to unwinding&cleanup, an Error to termination
(with unwinding&cleanup in debug mode for debugging purposes).
What would you like to discuss here?
