Scenario: OpenSSL in D language, pros/cons

[Jonathan M Davis via Digitalmars-d]

On Tue, 06 May 2014 09:56:11 +0200
Timon Gehr via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On 05/05/2014 12:41 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Regardless, there's
> > nothing fundamentally limited about @safe except for operations
> > which are actually unsafe with regards to memory
>
> What does 'actually unsafe' mean? @safe will happily ban statements
> that will never 'actually' result in memory corruption.

@safe is supposed to ban any code where it can't prove that it can't access
memory that it shouldn't - be it to read from it to write to it - as well as
code that it can't prove will not result in other code accessing memory that
it shouldn't have access to. It's quite possible that some code which
shouldn't be being banned is currently being banned, and it may be the case
that we'll be stuck with some code being banned simply because we can't make
the compiler smart enough to know that it doesn't need to ban it (though
hopefully that's kept to a minimum). But @trusted is there precisely for the
situations where an operation is unsafe in the general case but is perfectly
safe in a specific case based on information that the compiler does not have
access to but the programmer does (such as knowing that certain values will
never be passed to the given function).

However, I don't think that there's much question that at this point @safe
isn't quite correct. There are definitely cases right now that are considered
@safe when they shouldn't be (e.g.
https://issues.dlang.org/show_bug.cgi?id=8838 ), and I expect that there are
also cases where code is considered @system when the compiler should consider
it @safe (though I don't know of any of those off the top of my head).

- Jonathan M Davis