Detached unit tests

[Richard (Rikki) Andrew Cattermole]

On 01/05/2024 5:29 AM, Jonathan M Davis wrote:
> 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.

Static in the context of a type like a class implies no this pointer, a 
unittest should never have one to begin with, therefore it doesn't fit.

For this reason I do not like it.

> 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.

I'd go for a UDA in core.attribute.

For finer grained control that is a great way to do it, since most 
people won't need it.

> 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).

This is what I proposed on Discord.

We can change this behavior for newer editions. No reason to break 
existing code.