On Friday, 6 February 2015 at 17:13:09 UTC, Zach the Mystic wrote:
It's been suggested that '@system' be used to mark the blocks in question. The point would be to emphasize the dangerousness of the operation. The function is still @trusted, but inside, the @system code is marked as such.
This is precisely equivalent to just making the function @safe and using @trusted blocks inside (which is incidentally my preferred approach, and similar to what parts of Phobos try to emulate).
As I argued almost three years ago in my "@trusted considered harmful" post, @trusted doesn't differ in meaning from @safe for API clients. Both mean that you can call the function from @safe code, nothing more, nothing less. I hope we agree on that.
You might argue that having @trusted in the function declaration serves as an indicator that the implementation requires extra careful review. However, there will *still* be a @trusted keyword sitting in the source code and staring at your face even with @trusted blocks. And if you don't have the source code for a function you call to begin with, all bets are off anyway (i.e. you need to trust its author) as @safe functions may always internally call @trusted ones.
If the leadership feels that your proposal is to be preferred because it keeps @trusted in the function signature (as he correctly remarked, the safety of @trusted blocks might depend on surrounding @safe code), then so be it. However, it makes an implementation detail part of the API (see "@trusted considered harmful"), and furthermore is not backwards-compatible.
David
