Code That Says Exactly What It Means

[H. S. Teoh]

On Thu, Oct 30, 2025 at 05:53:15PM +0000, Steven Schveighoffer via Digitalmars-d wrote:
> 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”. ;)

lol, to further distance ourselves from C++, we should introduce the
'enemy' keyword in lieu of 'friend'. :-P


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

Yes.

Though we already have a related (but tangential) issue with this inside
templated aggregates: if the template never gets instantiated, none of
the unittest blocks inside it would ever instantiate.  And the unittests
would also instantiate multiple times, once per instantiation, which
leads to a lot of bloat when the tests don't actually depend on the
template arguments of the current instantiation (i.e., they manually
specify specific instantiations that they are testing).


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

Do I smell a further abu^Wextension of the 'static' keyword to prevent
unittests from accessing private members? ;-)

```d
	/// Your average typical ddoc'd aggregate
	struct Stuff {
		private int x;

		/// Your average typical member function
		void member() {}

		/// My awesome ddoc'd unittest!
		static unittest {
			Stuff s;
			s.x; // error: cannot access private member x
		}
	}
```


T

-- 
Synonym rolls: just like grammar used to make them.