Future of SafeRefCounted

[Dukc]

On Saturday, 22 February 2025 at 19:05:49 UTC, Dukc wrote:
> Which leads to another issue: language modules and Phobos 3.

Wow, how did I write about modules all the way down without 
noticing? I meant *editions* in all but one instance. So:

Which leads to another issue: language editions and Phobos 3.

My understanding is the current plan with Phobos 3 is to not
use DIP1000 in it. `SafeRefCounted` depends on DIP1000. Without
it it isn't any better than the old `RefCounted` type.

Surprisingly, this doesn't automatically mean it can't be done
in Phobos 3. Within the present language it wouldn't be
possible, but editions are going to change the calculus.

In the future when DIP1000 is on or off per module as opposed
to compilation unit, it is going to the client code which has
to be DIP1000 for ref counting to be safe. The reference
counted type can be implemented with our without DIP1000 just
as well (although non-DIP1000 implementation of `borrow` would
probably need a [currently
missing](https://github.com/dlang/dmd/issues/20302) ability to
manually inspect the scopeness of the argument function -
currently the safety is inferred by calling the argument
function with a `scope` argument which probably doesn't work
outside DIP1000. Also `@safe`ty unit tests of it would need
DIP1000.).

Editions are also one more reason to do away with inspecting for
DIP1000. With editions, the current definition of the inspection
```D
private auto dip1000Test(int x) {return *&x;}
// Used in the `static if`
package(std) enum dip1000Enabled
     = is(typeof(&dip1000Test) : int function(int) @safe);
```
is going to inspect Phobos, not the client code. While we're
probably going to have a way to inspect client code instead,
IMO it is a code smell if you're inspecting the edition /
completion flags of your client code.

What are your thoughts?