@trusted attribute should be replaced with @trusted blocks

Paul Backus snarwin at gmail.com
Thu Jan 16 01:07:21 UTC 2020

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.

More information about the Digitalmars-d mailing list