On Sunday, 30 August 2015 at 14:08:15 UTC, Dicebot wrote:
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
While your proposal sounds interresting to start with I don't
like some of the implications:
1) You force people to write unittest. If people don't write a
export unittest block their templates won't work across shared
library boundaries.
2) A template in D might get __very__ complex. To make sure that
each and every function needed is actually exported your
unittests would need to have 100% coverage. Looking at some of
the template code in phobos this won't be any more fun than
manually putting export in front of every required function.
3) Its going to be hard to implement. You basically need to touch
all the template instanciation code and make sure it tells you
which functions have been used after its done. Thats going to be
quite invasive.
4) Martins favorite argument. When doing C APIs you usually
ensure that you public interface (e.g. whats exported form a
shared library) stays the same between minor versions. This
automatic export thing is going to make this a lot harder for D.
