Possible solution for export : `unittest export`?

[Dicebot via Digitalmars-d]

On Tuesday, 1 September 2015 at 12:55:11 UTC, Benjamin Thaut 
wrote:
> 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.

I think it is a nice encouragement but in context of the proposal 
it is
optional - you can remove error for not covering export template
with test if someone wants to do it manually.

> 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.

True, that is why I am stressing the point about 
https://issues.dlang.org/show_bug.cgi?id=14825 - if it gets 
fixed, putting exported API in separate module and checking for 
strict 100% cov in CI system allows for quite a reliable 
maintenance.

Phobos is a bit special though because it is dominated by 
independent
template utilities and vast majority of symbols is public anyway. 
For that just
slapping top-level module `export:` may be a better option. I am 
not
interested in Phobos much personally though :)

> 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.

Can't say much here, need someone more experienced with DMD to 
comment.
Tweaking all template semantic phase doesn't seem that invasive 
to me,
hardest part is transitivity - if export template `foo` uses 
non-export template `bar` which uses plain function `baz` you 
still want to put `baz` into the
binary. That may be hard to retro-fit into existing semantic step 
system in
DMD as I remember it.

> 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.

How so? Important thing about my proposal is that those 
"implicitly"
exported symbols are not considered public, they merely are 
available
for linkage. Anyone relying on presence of symbols that are not 
defined
by header / .di distributed by the library is asking for trouble 
anyway. It is like trying to link directly to functions in C 
which are marked as `static inline` but present in object file 
with obfuscated name because of address exposure.