Possible solution for export : `unittest export`?

Benjamin Thaut via Digitalmars-d digitalmars-d at puremagic.com
Tue Sep 1 05:55:10 PDT 2015


On Sunday, 30 August 2015 at 14:08:15 UTC, Dicebot wrote:
> 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

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.


More information about the Digitalmars-d mailing list