Follow-up to old
http://forum.dlang.org/thread/[email protected]
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
