On attribute inference...

[Satoshi via Digitalmars-d]

On Tuesday, 19 April 2016 at 08:57:21 UTC, Jonathan M Davis wrote:
> On Tuesday, April 19, 2016 07:58:19 Satoshi via Digitalmars-d 
> wrote:
>> Why cannot be exported every public/protected method by 
>> default? When I am creating so/dll I want to export almost 
>> everything. Methods what I dont want to export I should mark 
>> as private or package or package(nameOfRootPackage).
>
>>From the standpoint of simplicity, that's definitely nicer. 
>>With C/C++ and
> Linux, the default is that all symbols in a shared library are 
> visible, whereas on Windows, on those which are explicitly 
> exported are visible, and I always found having to deal with 
> building on a Windows a royal pain - especially when what I had 
> done just worked on Linux.
>
> However, there are some good arguments for not just exporting 
> everything - particularly with regards to compilation 
> efficiency. It's not that uncommon for a library to have a 
> public API that everyone should see and use while having a 
> bunch of functions that are used only internally and really 
> shouldn't be exposed to users of the library. To some extent, 
> package can be used to hide those, but the larger the library, 
> the harder that gets. And if a library is very deep (i.e. its 
> functions do a lot for you), then you're fairly quickly going 
> to end up with functionality that ideally would be hidden, and 
> putting everything in one module or package isn't always 
> reasonable. As it is Phobos has std.internal which is 
> theoretically not supposed to be used outside of Phobos, but 
> it's completely importable and usable by any code using Phobos. 
> Having code like that restricted by export could be desirable.
>
> I expect that hiding symbols which aren't public would 
> certainly help a great deal in avoiding having a lot of 
> unnecessary symbols in a compiled library, but it doesn't 
> completely solve the problem. And when discussions on export 
> have come up, some of the folks who are particularly 
> knowledgeable on the subject have been _very_ much in favor of 
> using export to restrict what is and isn't visible in the 
> generated library rather than relying on public. They'll have 
> to chime in to provide good details though. The main issue that 
> I recall is the desire/need to reduce the number of symbols in 
> order to make compiling/linking more efficient.
>
> - Jonathan M Davis



But when I create two versions of the same library (shared and 
static one). Public symbols will be accessible through the static 
library but inaccessible through the shared library.

Library is a one big package and marking symbols as 
package(MyLib) is same as mark them as public in shared object.

e.g. I have MyLib and TestApp
MyLib
  - math.d
  - foo.d
  - bar/test.d

TestApp
  - main.d

or subpackages like
rikarin.core;
rikarin.appkit;
rikarin.base;
rikarin.backend;
etc.

I can easily create internal methods through the package(rikarin) 
definition. And package symbols shouldn't be exported.