On 4/13/15 10:49 AM, Dicebot wrote:
On Monday, 13 April 2015 at 14:42:33 UTC, Steven Schveighoffer wrote:
This is exactly what "explicit API" thing is about. If symbol is
`export` it must have explicit attributes. If it isn't, inferring is
fine because no promises are actually made.
I thought 'export' was for dll/so?
It is necessary for dll/so but the very same definition makes it
naturally suitable for denoting any API that must persist through binary
boundaries. It does not have any special effects other than simply
saying "this symbol must be accessible externally".
For instance, no phobos code has export attributes. I've never written
one for my private libraries either.
In order for this to work, code that is "external" better not be able
to call any non-export functions. This is not a change I think we
should pursue.
Why so? It is only a problem for export templates, because compiler
can't verify the attributes until it is instantiated. For fixed symbols
there are no restrictions on what can be called - all called functions
have attributes inferred and compiler verifies that result matches what
programmer has put on API function itself.
It's a problem for any API code that is not a template, because it
currently does not have inferred attributes, but now it will because you
didn't put "export" on it. This means you have assumed that every piece
of code written without "export" is not public API, when in most cases,
it actually is because it's public.
Or am I reading this wrong?
-Steve
