https://issues.dlang.org/show_bug.cgi?id=21462
Mathias LANG <pro.mathias.l...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pro.mathias.l...@gmail.com
--- Comment #1 from Mathias LANG <pro.mathias.l...@gmail.com> ---
If one wants unittest to only test a certain visibility level, one may place
the unittest in a different module. Conventions may arise (Tango used
`modname_test.d` IIRC). Adding a language feature for this use case seems a bit
too much.
Additionally, it would most likely "get in the way" of most unittests. The
point of a unittest is to be a conformance test at the lowest level. Hence, it
is normal for unittests to test internals of a data type, private members or
functions, etc...
Going back to the problem, the root of your reasoning is that the unittest
would not compile at usage site. But the only unittests that should likely
compile outside of the module are *documented unittests*.
Introducing a check that only non-private members are called in a documented
unittest *might* work, but some people (like myself) are writing documented
unittests even for internal helpers, so it should be possible to opt-out (or be
opt-in).
All things considered, this sounds like a good addition to DScanner.
--
