Problem with coupling shared object symbol visibility with protection

[Benjamin Thaut via Digitalmars-d]

On Wednesday, 28 January 2015 at 11:42:19 UTC, Dicebot wrote:
>
> 2) first proposed solution does not allow to mark private 
> functions as "export". It implicitly exports those if they are 
> needed for actual public/export template function to work. This 
> is not the same - those functions still can't be called via 
> provide .di binding, it simply keeps them available for linking.

So you would prefer to keep symbols private and just make them 
available for linking? Or what exactly is the message here?

>
> 3) there is a big maintenance benefit from encouraging people 
> to explicitly mark their API, template or not. It is a clear 
> sign "this is a part of my libraries you are expected to use 
> directly" and that was what my idea for attribute inference 
> abused.

Agree here. Especially if you want to keep your shared library 
backwards compatible, so that people can simply drop in the new 
binary. To do that you need very fine control over what is 
exported and what is not.