DIP 1028---Make @safe the Default---Community Review Round 1

Manu turkeyman at gmail.com
Thu Jan 9 00:12:23 UTC 2020

On Thu, Jan 9, 2020 at 5:01 AM Timon Gehr via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 08.01.20 08:10, Arine wrote:
> >
> > @trusted doesn't really make sense. It is pretty much @system that @safe
> > can call. It's actually kind of bad as how easily it can be misused.
> > @trusted: comes to mind. You can have @trusted destructors. So when you
> > are reading @safe code you can't easily tell where potentially @unsafe
> > code is located. As the @trusted is applied to the function, not at the
> > call site (like Rust/C#).
> > ...
> This line of reasoning makes no sense.
> @trusted void foo(T...)(T args){ ... }
> is like
> @safe void foo(T...)(T args){ unsafe{ ... } }
> It's the same thing. The point is that the interface of foo is assumed
> to safe by all callers even though the implementation might not be.
> > If we are going to make @safe the default we don't really need @safe
> > keyword, or @system or @trusted. It's make sense to get rid of all 3 of
> > them and just add @unsafe. If you are going to do it, might as well do
> > it right the first time.
> I don't care all that much either way, but let's not pretend that what
> you propose is different to what we have in any important way other than
> how convenient certain things are to express. Adding trusted statement
> blocks and deprecating `@trusted:` annotations would have essentially
> the same effect.

unsafe blocks is distinctly preferable to me. Functions are usually >1
line, and I hate that we can only mark this at the function level.
Unsafely statements are never at the function level, it's usually just
one line among a larger function. An unsafe scope would be immensely
preferable to me, because I can make it as narrow as the code i'm
suspicious of, and the surrounding code doesn't lose its safe checking
just by being a bystander.

More information about the Digitalmars-d mailing list