As far as I know @safe is only really safe with both DIP25 and DIP1000 in effect, and I thought that DIP25 has been integrated for a while now. Nonetheless, DIP25 still appears in the list of previews (dmd -preview=help) as well as being revertible (dmd -revert=help) which adds to the confusion.

What is in the way of integrating DIP1000 by default?

-- Bastiaan.

On Monday, 3 January 2022 at 14:27:55 UTC, Bastiaan Veelo wrote:

Bugs, and lots of them.

• Alex

On Monday, 3 January 2022 at 15:19:22 UTC, 12345swordy wrote:

But are these bugs in the rigidity of the checks, or do other problems arise when DIP1000 is enabled? If it is just the former, there is little reason to not switch it on by default? Does it produce false negatives (requiring @trusted where unnecessary)?

And does -preview=dip25 make a difference or not? Still confused.

--Bastiaan.

On Monday, 3 January 2022 at 16:06:38 UTC, Bastiaan Veelo wrote:

The problem is usually that the checks are too loose--they allow undefined behavior in @safe code when -preview=dip1000 is enabled.

You can browse the list yourself here: https://issues.dlang.org/buglist.cgi?quicksearch=dip1000

On Monday, 3 January 2022 at 14:27:55 UTC, Bastiaan Veelo wrote:

Conceptually, DIP 1000 does not make your existing @safe code any safer. It allows some code to be @safe that had to be @system before.

If you just want to write @safe code, and you don't care for scope, you can ignore DIP 1000. Any safety holes are just bugs, with and without -preview=dip1000.

On Monday, 3 January 2022 at 14:27:55 UTC, Bastiaan Veelo wrote:

@safe is really safe - what DIPs 25 and 1000 do is make it so more code can be @safe.

I'm currently working on making DIP1000 the default.

On Tuesday, 4 January 2022 at 08:58:04 UTC, Atila Neves wrote:

Thanks, that clears things up considerably.

Great!

-- Bastiaan.

On Monday, 3 January 2022 at 16:06:38 UTC, Bastiaan Veelo wrote:

This is the situation on dmd's master branch:
✅ = correct, considering the current language design
🆗 = correct, but is more strict than necessary
💀 = incorrect, allows memory corruption

I'm trying to turn dip1000's 💀 into an 🆗, but Walter wants to go straight to a ✅:
https://github.com/dlang/dmd/pull/13362#issuecomment-981181277

On top of this, dip1000 currently has a few more 💀s because:

• parameters of pure functions can be incorrectly inferred scope, even when you can escape them with a thrown Exception. The fix is easy, but it requires updating Phobos and excel-d to pass the test suite, which is cumbersome.
  https://issues.dlang.org/show_bug.cgi?id=22221

• inout on struct member functions currently gives the permissions of return without the associated lifetime restrictions.
  https://issues.dlang.org/show_bug.cgi?id=20149

• Some checks are missing when using closures:
  https://issues.dlang.org/show_bug.cgi?id=22298

dip25 prevents returning a ref parameter by ref, unless you annotate it return ref. It's enabled by default, but only as a deprecation. -preview=dip25 turns the deprecation into an error. -preview=dip1000 implies -preview=dip25, so there's no need to use both switches.

On Tuesday, 4 January 2022 at 11:57:41 UTC, Dennis wrote:

This is really helpful, thanks!

-- Bastiaan.

On Tuesday, 4 January 2022 at 11:57:41 UTC, Dennis wrote:

I talked to Walter about this and I don't think it's the correct fix. I've been looking at how to do it otherwise.