@trusted attribute should be replaced with @trusted blocks

[Paul Backus]

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, and the ABI issue can be fixed by changing how 
@trusted affects name mangling.

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