Bug 18623 – Documented unittest should not allow private symbol access

private int i; /// unittest { i++; } `i` is not visible outside the module, so it should not appear in public documentation about how to use the module.

I agree though the compiler currently doesn't know whether the test is ddoc-ed when -D isn't passed. As it throws away all documentation text during parsing. For Phobos we use a workaround which extracts all public tests and puts them in separate files and then executes them: https://github.com/dlang/tools/blob/master/tests_extractor.d

I would vote to close this as WONTFIX. You may want to test things inside your unit test that have nothing to do with the example, but use the same code for setup, and then you have to write that code twice. It's pretty easy to say // private data, for testing only.

(In reply to Steven Schveighoffer from comment #2) > You may want to test things inside > your unit test that have nothing to do with the example, but use the same > code for setup, and then you have to write that code twice. If you really want your *documented* unittest not to be runnable by a user, you can wrap your private code in a free function with `protected` access as a workaround. > It's pretty easy to say // private data, for testing only. The whole point of this issue is for when the programmer is unaware that the documented example contains private symbols *unintentionally*. This is clearly a significant problem otherwise @greenify wouldn't have added a custom automated test for Phobos to check this. Copying and pasting from other tests is a classic trigger for this.

I agree that can be a valid concern. Let me restate that I would recommend if we do this, make it an opt-in switch.

Andrei and Walter are not really keen on adding more and more cli switches. The unittest extraction pipeline is far from ideal, but it's probably the best we will get in this sector.

FWIW the tools extractor that is used by Phobos is now on dub: https://code.dlang.org/packages/dtools dub fetch dtools dub run dtools:tests_extractor

@RazvanN7 created dlang/dmd pull request #13783 "Fix Issue 18623 - Documented unittest should not allow private symbol access" fixing this issue: - Fix Issue 18623 - Documented unittest should not allow private symbol access https://github.com/dlang/dmd/pull/13783

Closing as per comments in: https://github.com/dlang/dmd/pull/13783

From the pull: > If someone wants to document private symbols, why prevent it ? > In the example, the documented unittest is attached to a private symbol, isn't it ? If you want to support that unusual case, require private unittest to enable using private symbols in the documented test. (The documented unittest could even be inferred as private if the symbol it's documenting is private). I would like to reopen this.