Paul Backus

What's the motivation for this? Does this enable any specific usage that the previous version didn't? If so, the PR should include a unit test for that usage.

> only() can be used to initialize other types that accept a slice Isn't the entire point of using Voldemort types to prevent users from relying on the concrete types...

I'd say it's fine to use a `noreturn[]` as an implementation detail if it's the simplest way to support the desired use-cases, but the return type should still be `auto`...

Seems strange to close this outright. Why not label as "blocked" if it's only being held back by compiler issues?

The FreeBSD failure is an issue with the CI scripts. It should be fixed when #8454 is merged.

Maybe we can call the new version `generator` (similar to `joiner` and `splitter`).

This is the problematic case: ```d @safe unittest { auto rc = RefCounted!int(123); (ref int n) { destroy(rc); int oops = n; // use-after-free if allowed }(rc.refCountedPayload); } ``` As...

> Worse, I think this applies to about any pattern -dip1000 would enable: There is one pattern that can work here, which is a callback-based API: ```d auto ref apply(alias...

@Geod24 The destructor should reset `_refCounted` to `RefCountedStore.init` to ensure that it is idempotent even if `destroy!false` is used.

> I'm thinking about making the destructor `private`, and defining an UDA at DRuntime, let's say `noEarlyDestroy`. `destroy` would be `@system` for types annotated with that attribute. What do you...