On Friday, 15 February 2013 at 04:09:36 UTC, Martin Nowak wrote:
On 02/15/2013 03:49 AM, David Nadlinger wrote:
> On Fri, Feb 15, 2013 at 3:31 AM, Martin Nowak <[email protected]>
wrote:
>> Having the distinction at the API level makes perfectly
sense for this.
>
> Sorry, but where is the argument here?
>
> David
If you switch the perspective @trusted allows you to put a
constrain on code. Especially you can chose to NOT trust.
The SafeD compiler was not a good example because you have the
source code at hand and could inspect it for @trusted blocks.
But if you think of Chromes Native Client it becomes extremely
valuable that one could distinguish a function that requires
trusting vs. a function that is safe at the ABI level. One
could for example intercept and disallow function calls to
@trusted functions if a certain plugin is not trusted by the
user.
This is totally irrelevant to the current subject, as @trusted
code can be called from @safe code.
You are asking for another functionality here.
