@safe D requires which DIP switches?

Dennis dkorpel at gmail.com
Tue Jan 4 11:57:41 UTC 2022

On Monday, 3 January 2022 at 16:06:38 UTC, Bastiaan Veelo wrote:
> But are these bugs in the rigidity of the checks, or do other 
> problems arise when DIP1000 is enabled?

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

| Action                         | no dip1000 | dip1000           
| Take address of local variable | 🆗 Error   | ✅ Allowed using 
`scope` when type has no pointers  |
| Make slice of local variable   | 💀 Allowed | ✅ Allowed using 
`scope` when type has no pointers  |
| Take address of `ref` return   | 💀 Allowed | 🆗 Allowed using 
`scope` when type has no pointers |
| Make slice of `ref` return     | 💀 Allowed | 💀 Allowed even 
when type has pointers             |

I'm trying to turn dip1000's 💀 into an 🆗, but Walter wants to go 
straight to a ✅:

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.

- `inout` on struct member functions currently gives the 
permissions of `return` without the associated lifetime 

- Some checks are missing when using closures:

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

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.

More information about the Digitalmars-d mailing list