On Monday, 13 April 2015 at 15:47:44 UTC, Steven Schveighoffer
wrote:
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.
Yep, this is one of reason I think this is lucky coincidence. See
below.
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?
What I mean is that right now literally no one actually states
any clear API stability, attribute inference or not. Sometimes it
happens to work, sometimes it doesn't - there is no culture of
providing such guarantees. The fact that export is almost unused
provides and opportunity to set up such culture in a way endorsed
by a language - by stating intended purpose in release X, fixing
it for shared libraries in release X+1 and enabling attribute
inferences in releases X+2 / X+3 (optionally -> mandatory).
That way people will be forced to slowly review their code to
actually make decisions what IS public API and how it must be
defined. Saying that current public methods define API is
incredibly far from truth unless you mean only Phobos. I'd like
that to become explicit deliberate decision in the long term.
