On attribute inference...

[Jonathan M Davis via Digitalmars-d]

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