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

[Manu]

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.