@system blocks and safer @trusted (ST) functions

[Bruce Carneal]

At beerconf I committed to putting forward a DIP regarding a new 
syntactic element to be made available within @trusted functions, 
the @system block.  The presence of one or more @system blocks 
would enable @safe checking elsewhere in the enclosing @trusted 
function.

I also committed at beerconf to starting the formal DIP on this 
in two weeks so I read the DIP docs just now in order to get a 
jump on things.  Boy, that was an eye-opener.  From the 
incessantly cautionary language there I'd say that I dramatically 
underestimated the effort required to bring a DIP over the finish 
line (or to see it clearly rejected).

Long story short, I'll still do the DIP unless the ideas are 
discredited in subsequent discussion but it will have to be quite 
a bit later in the year as I dont have weeks of time to spend on 
it in the near future.  In the mean time I'd invite others to 
comment on the ST (safer @trusted) idea as sketched in the first 
paragraph.  For starters, we might come up with a better name...

A few notes:

1) Since @system blocks would be a new syntactic element I 
believe ST would be a backward compatible addition.

2) The problematic @trusted lambda escapes creeping in to "@safe" 
code could be replaced going forward by a more honestly named 
form, @trusted code with @system blocks.  Best practices could 
evolve to the point that @safe actually meant @safe again.

3) I believe quite a bit of @trusted code is @safe but can not 
currently benefit from automated checking.  The proposal would 
allow a transition of such code to an @safer form while reducing 
the amount of code that requires intense manual checking.

4) @safe blocks within @trusted code were considered but left 
things defaulting in a less useful direction (and they're just 
plain ugly).

Questions and improvements are very welcome but, in the dlang 
tradition, I also welcome your help in destroying this proposal.