@trusted attribute should be replaced with @trusted blocks

[Johannes Pfau]

Am Thu, 16 Jan 2020 04:34:26 +0100 schrieb Timon Gehr:

> On 16.01.20 03:06, Joseph Rushton Wakeling wrote:
>> On Thursday, 16 January 2020 at 01:53:18 UTC, Timon Gehr wrote:
>>> It's an implementation detail. If you care about the distinction, you
>>> should check out the function's implementation, not its signature.
>> 
>> Sure. But on a practical day-to-day basis, @safe vs @trusted signatures
>> help to prioritize one's allocation of care somewhat.
>> ...
> 
> You have to be careful when writing a @trusted function, not when
> calling it. If you do not trust a given library, there is no reason to
> be more careful around a @trusted API than around a @safe API, as they
> do not mean different things.
> 
> @safe does not fully eliminate risk of memory corruption in practice,
> but that does not mean there is anything non-absolute about the
> specifications of the attributes. As I am sure you understand, if you
> see a @safe function signature, you don't know that its implementation
> is not a single @trusted function call, so the difference in signature
> is meaningless unless you adhere to specific conventions (which the
> library you will be considering to use as a dependency most likely will
> not do).
> 
> 
>> I'm coming to the conclusion that much of the differences of opinion in
>> this thread are between folks who want to see things as absolutes, and
>> folks who recognize that these features are tools for mitigating risk,
>> not eliminating it.
>> 
>> 
> I was not able to figure out a response to this sentence that is both
> polite and honest.


I'm curious, what do you think would be the ideal scheme if we could 
redesign it from scratch? Only @safe/@system as function attributes and 
@trusted (or @system) blocks which can be used in @safe functions?



-- 
Johannes