On Friday, 28 November 2014 at 22:54:42 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Wednesday, November 26, 2014 16:27:53 David Held via
Digitalmars-d-learn wrote:
On 11/23/2014 3:12 PM, anonymous wrote:
> [...]
> And even pointer dereferencing is @safe. Invalid ones will
> fail
> with a segfault at run time:
> void foo(int* a) @safe {*a = 13;}
Hmm...throwing an exception is a well-defined behavior, but is
segfaulting a well-defined behavior of correct D programs?
This seems
like a peculiar definition of "safe" to me...
@safe is about guaranteeing that memory will not be corrupted
and that any
memory that's accessed has not been corrupted. Segfaults don't
corrupt
memory and don't allow you to access corrupted memory. Rather,
it's the OS
catching that your program has accessed memory that it
shouldn't and then
essentially killing your program. The OS is _preventing_ any
possible
memory corruption. So, as much as robust programs shouldn't
segfault,
segfaults are perfectly safe with regards to memory - which is
what @safe is
all about.
- Jonathan M Davis
So what about forbidding this in nothrow functions? My vision
with D is to be able to get more guarantees about stability than
all other imperative languages. If the compiler cannot prove that
alignments and memory regions match then a safe nothrow function
doing these casts should IMO fail at compile time.
