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.
