Discussion Thread: DIP 1028--Make @safe the Default--Final Review

Jonathan M Davis newsgroup.d at jmdavisprog.com
Fri Mar 27 21:02:52 UTC 2020


On Friday, March 27, 2020 9:40:00 AM MDT Adam D. Ruppe via Digitalmars-d 
wrote:
> On Friday, 27 March 2020 at 09:07:01 UTC, Walter Bright wrote:
> > BTW, I have an upcoming DIP that changes the default attributes
> > for delegate parameter types to match the function they appear
> > in.
>
> You'd probably have to make an exception there for @trusted... if
> a @trusted function takes a @trusted delegate it would get
> silently ugly.
>
> OR perhaps
>
> @trusted void foo(@trusted void delegate) { }
>
>
> foo( () { /* do unsafe thing */} ); // fails to compile unless
> the body infers to @safe, it will never assume a @system literal
> is trusted
>
> foo( () @trusted { /* do unsafe thing */}); // OK, you
> specifically said trusted so it works

@trusted should never have been part of the name mangling / linkage of D
functions. @trusted and @safe need to be treated very differently when
compiling functions, and they signal very different things to the
programmer, but their difference is an implementation detail. A function
calling an @safe or @trusted function doesn't care about the difference, and
all it takes is one @safe function in-between, and an @trusted function
effectively becomes an @safe one anyway. If @trusted just mangled to the
same thing as @safe, then that definitely improves the situation for stuff
like delegates (not fix it given the attribute soup that we have, but it
would certainly improve it).

I don't know if we can reasonably change how @trusted is treated in name
mangling at this point, but I definitely think that it was a mistake to
distinguish between @safe and @trusted with name mangling.

- Jonathan M Davis





More information about the Digitalmars-d mailing list