On 07/28/2012 02:08 AM, David Nadlinger wrote:
1) Remove the distinction between @safe and @trusted at the interface
(ABI, API) level. This implies changing the name mangling of @trusted to
Nf, and consequently removing the distinction in DMD altogether (at
least in user-facing parts like .stringof and error messages). In
theory, this is a breaking change, but as any code that doesn't treat
them the same is buggy anyway, it shouldn't be in practice. As for
std.traits.FunctionAttribute, we could either make trusted an alias for
safe, or just remove documentation for the former and keep it around for
some time (there is no way to deprecate an enum member).
I haven't read through the whole thread, so pardon if that argument
already came up.
I think you're missing an important point here.
SafeD is a subset of the language @trusted is not.
It's very reasonable to implement a compiler that supports only SafeD.
It's probably not feasible to translate @system to javascript for
example [1].
Having the distinction at the API level makes perfectly sense for this.
It's also another use case for attribute overloading ;-) [2].
[1]:
http://forum.dlang.org/thread/[email protected]#post-yfmgvgprfpiquakiyjlk:40forum.dlang.org
[2]: http://d.puremagic.com/issues/show_bug.cgi?id=9511
