@trusted attribute should be replaced with @trusted blocks

[Timon Gehr]

On 16.01.20 02:07, Paul Backus wrote:
> On Wednesday, 15 January 2020 at 14:30:02 UTC, Ogi wrote:
>> If you think of it, it makes no sense for @trusted to be a function 
>> attribute. It doesn’t describe its behavior but its implementation. If 
>> you call a function, it should not be your concern; @safe and @trusted 
>> are the same thing for you. But these two attributes result in two 
>> different signatures. If a function expects a @safe callback, you 
>> can’t pass a @trusted function to it without @safe wrapping. If some 
>> library makes a function that used to be @safe @trusted, that’s a 
>> breaking change. Etc, etc. Why should we introduce complexity out of 
>> nowhere?
> 
> To me, this is the only part of the argument against @trusted that's 
> really convincing. Having the @safe/@trusted distinction be part of the 
> type system and the ABI is almost 100% downside, and changing that would 
> eliminate some pain points at essentially no cost to the language.
> 
> However, both of these issues can be fixed without a huge overhaul of 
> @trusted. The type-system issue can be fixed by introducing implicit 
> conversions between @safe and @trusted functions,

That's already how it works. The OP just didn't bother to check whether 
the claim is true:

void main(){
     void delegate()@safe dg0=()@trusted{}; // ok
     void delegate()@trusted dg1=()@safe{}; // ok
}

> and the ABI issue can 
> be fixed by changing how @trusted affects name mangling.
> ...

It's not just the ABI, it's also static introspection. The way to fix 
that is to treat `@trusted` functions as `@safe` functions from the 
outside. (E.g.., `typeof(()@trusted{})` would be `void delegate()@safe`.)

> Once these issues are fixed, the only remaining benefits of the proposed 
> overhaul are cosmetic, and IMO not worth the disruption they would cause.
>