Possible solution for export : `unittest export`?

[Dicebot via Digitalmars-d]

Follow-up to old 
http://forum.dlang.org/thread/m9lhc3$1r1v$1@digitalmars.com 
thread by Benjamin

Short reminder of the issue:

Currently unsolved issue with finishing `export` implementation 
is lack of convenient semantics for its interaction with 
templates. If template function is marked as `export`, its 
non-template dependencies (called functions) will also need to be 
marked as effectively export (even if private) to be put in 
object file and avoid linker errors.

Which is impossible to do automatically because dependencies 
can't be figured out without instantiaton. And to do it manually 
you'd need to mark all dependencies with `export` too which is 
impossible without making them also public because currently 
`export` is defined as protection attribute. One of Benjamin 
proposals was to split it as a separate attribute kind but doing 
all manual annotation would still be hardly convenient / 
maintainable.

Proposal essentials:

Define `unittest export { /* tests here */ }` which will verify 
that all directly used symbols from same module/package are 
marked as export and automatically mark dependencies for 
placement into object files while doing semantic phase for tested 
instances.

Rationale:

- fits existing "documented unittest" feature by providing 
verified example of using the API
- easier change to grammar than re-defining export itself
- reasonably simple maintenance (no need to hunt each small 
dependency function after internal changes, risking linker errors 
if sloppy)
- if https://issues.dlang.org/show_bug.cgi?id=14825 is ever 
fixed, combining this with -cov will ensure reasonable confidence 
in proper API annotation

Cons:

- implies test author to be smart enough to do all necessary 
instantiations (will become less of an issue with 
https://issues.dlang.org/show_bug.cgi?id=14825)
- may look like a hack for those coming from more restrictive 
languages