Mitigating the attribute proliferation - attribute inference for functions

[Steven Schveighoffer via Digitalmars-d]

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