Code That Says Exactly What It Means

[Steven Schveighoffer]

On Thursday, 30 October 2025 at 16:02:36 UTC, jmh530 wrote:

> Steve’s point was a little confusing. He said it’s a unit test 
> problem and not an accessibility problem. Regular unit tests 
> should be able to access the rest of the module but documented 
> unit tests shouldn’t. But would we really want to strictly 
> enforce that for documented unit tests?  The point might be 
> that it’s not an issue of other parts of the module accessing 
> the internals of the unittest, it’s about the ability of the 
> unittest to access the private elements of the module. So I 
> don’t think the equivalent of scope-private would solve that 
> issue. You would need to make everything else in the module 
> scope-private instead of private, which you may not want to do. 
> Seems like it would need something else. Maybe instead of a 
> “friend” you would need an “enemy”. ;)

If you look at it another way, you can't document usage with a 
unittest that is not inside the module. There simply isn't a way 
to tie an external unittest to the function, it has to go right 
after it.

This is a unittest problem, but in fact, it's very nice to have 
the documented unittest required to be right after it (for 
maintenance purposes). The better solution is to prevent 
documented unittests (or at least provide the *ability* to 
prevent) from accessing private data.

-Steve