Detached unit tests

[Jonathan M Davis]

On Tuesday, April 30, 2024 11:02:51 AM MDT Steven Schveighoffer via dip.ideas 
wrote:
> I want to propose that we provide a mechanism to semantically
> detach unit tests from the scope they are written in. Such
> unittests would be treated as if they were not in the same scope
> or module. This includes detached unit tests inside templates.
> The only stipulation is that the current module is assumed
> imported.
>
> For a strawman syntax, let's do what everyone does ... overload
> `static`!

It would be valuable for ddoc-ed unittest blocks, because it would allow us
to guarantee that they don't use any part of the API which isn't public.
Phobos currently has to do that by running a separate program to pull out
all of the tests and make sure that they're runnable outside of the module,
which is a lot more complicated and doesn't help anyone else.

As for the syntax, static is probably fine so long as

static:

is ignored. I don't recall at the moment how much that affects, but it's
terrible practice to use static that way anyway given how little sense it
makes to try to apply static to multiple symbols at once.

When I'd thought about this the other day, I'd thought that maybe we could
use a pragma for it, but I don't really care much about the syntax, and
static seems fine. It fits in with the basic meaning of how static is
normally used.

Part of me thinks that we should just make ddoc-ed unit tests do this
without additional syntax, but that would undoubtedly break existing code,
since _someone_ will have a documented test somewhere that accidentally uses
a private member, and it might also help with templates to be able to do
this with undocumented unittest blocks (though I vaguely recall seeing
something about how the behavior on those was changed at some point so that
they're already not part of the template any longer, though I'm not sure on
that, since I haven't written any templated types with tests inside them
recently).

- Jonathan M Davis