On 17.11.2017 15:53, Jonathan M Davis wrote:
On Friday, November 17, 2017 15:05:48 Timon Gehr via Digitalmars-d wrote:
On 17.11.2017 12:22, Jonathan M Davis wrote:
On Friday, November 17, 2017 09:44:01 rumbu via Digitalmars-d wrote:
I know your aversion towards C#, but this not about C#, it's
about safety. And safety is one of the D taglines.
Completely aside from whether having the compile-time checks would be
good or not, I would point out that this isn't actually a memory safety
issue.
Memory safety is not the only kind of safety. Also, memory safety is
usually formalized as (type) preservation which basically says that
every memory location actually contains a value of the correct type.
Hence, as soon as you have non-nullable pointers in the type system,
this_becomes_ a memory safety issue.
This is definitely not how it is viewed in D. Walter has repeatedly stated
that dereferencing a null pointer is considered @safe, because doing so will
not corrupt memory or access memory that it should not access - and that's
all that @safe cares about.
The current discussion is about how safety *should* be viewed in D in
the future, as in, potentially /changing/ how it is viewed. This means
rehashing the status quo without giving justification for it is not
useful. Why *should* @safe only mean "does not corrupt memory" or
"accesses memory that it should not access"? Why can't it also mean
"does not attempt to dereference null pointers"? Note that it is up to
the language to _define_ what @safe does and does not mean. If the
language evolves, that meaning may evolve too.
