Mitigating the attribute proliferation - attribute inference for functions

Dicebot via Digitalmars-d digitalmars-d at puremagic.com
Mon Apr 13 08:56:47 PDT 2015


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.


More information about the Digitalmars-d mailing list