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.
