On Tue, 06 May 2014 09:56:11 +0200 Timon Gehr via Digitalmars-d <digitalmars-d@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