On the future of DIP1000

[Walter Bright via Digitalmars-d-announce]

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.