Mitigating the attribute proliferation - attribute inference for functions

[Dicebot via Digitalmars-d]

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".

> 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.