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

[Manu]

On Wed, Jan 8, 2020 at 5:15 PM Arine via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Wednesday, 8 January 2020 at 02:48:19 UTC, Walter Bright wrote:
> > On 1/6/2020 3:59 PM, Manu wrote:
> >> Well all feedback I've received is that it fails at the rule
> >> of least
> >> surprise. Definitely not intuitive what it means.
> >
> > I'm frankly surprised at this. Yours is literally the first
> > complaint about using `system` in 10 years that has come to my
> > ears.
> >
> > Also, a safe/unsafe dichotomy can make sense. But a
> > safe/trusted/unsafe makes less sense, like a 3 state boolean.
>
> @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#).
>
> 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.
>
>
> @safe void potentialProblem() {
>      A a;
>
>      where();
>      is();
>      the();
>      potential();
>      problem(here ? maybe() : maybeNot());
> }
>
>
> // safe by default //
> void potentialProblem() {
>      A a;
>
>      where();
>      is();
>      unsafe {
>          the(); // easily identifiable
>      }
>      potential();
>      problem(here ? maybe() : maybeNot());
> }

Actually, this is a really good point! I've had this thought many times.