On 8/21/2016 7:01 PM, Jonathan M Davis via Digitalmars-d-announce wrote:
Well, if you typically try and restrict your @system code to small parts of
your program and use @trusted to turn them into @safe, then the vast
majority of your program will be @safe. As I understand it, that's at least
how it was _intended_ that @system be dealt with - though plenty of folks
just don't bother with @safe, and it's certainly the case that code out
there doesn't restrict the @system portions as much as it could.
So, at least _in theory_, if you're using @safe as intended, even if you
have a fair number of code snippets which are @system, you can take
advantage of stuff like scope in most of your code. I don't know how well
that will work in practice though.
I can think of two big reasons to restrict something like this to @safe code
though. One is that implementing something like this usually means declaring
some stuff illegal that is actually safe, because the compiler can't be
perfect about it (a similar example would be how a lot of lambdas end up
allocating closures in order to be @safe when they don't actually need to;
the compiler simply isn't smart enough to figure out that it isn't necessary
and may or may not be able to with what the language allows the programmer
to do). Another reason is that sometimes in order to make certain
guarantees, the compiler has to be able to assume things that aren't
necessarily true in @system code, even if they happen to be true for most
@system code.
I agree. If there's a lot of @system code in a program, something has gone awry
in its design. I understand the desire to be able to turn each individual safety
feature on and off, but don't think the code really will be better off that way.
