@api: One attribute to rule them All

[Zach the Mystic via Digitalmars-d]

On Friday, 9 January 2015 at 11:40:28 UTC, Dicebot wrote:
> I think that push for more inference / WPO is an important goal 
> for D. However I had somewhat more radical and generic changes 
> in mind, ones that don't add new keywords or semantics but 
> rather strictly define what existing ones mean. This was 
> supposed to be turned into a DIP at some point (possibly after 
> consulting with Walter) but here is the draft outline:
>
> - separate compilation in basic C sense becomes illegal
> - minimal legal unit of separate compilation is defined as 
> static library
> - any time library gets built, it _must_ be distributed with 
> matching .di interfaces. If there are original .d files 
> imported, one must not try to link prebuilt library.

This last one is where all the threats from bad linking seem to 
come from.

> - .di generation is split in two modes:
>     1) 'minimal' (API) which only writes exported symbols and 
> ignores even public ones. All inferred attributes gets written 
> explicitly there. This is what gets recommended for public 
> distribution (even if it is source-only distribution) and what 
> defines stable API.
>     2) 'full' mode which is similar to existing .di generation 
> but with all attributes explicitly written to all functions. It 
> is approach recommended for creating intermediate built 
> artifacts (such as dub building of dependencies).

To sum up: All .di function signatures will now be generated with 
both explicit and inferred attributes. The keyword 'export' will 
be overloaded with a new meaning, toggled on and off by a 
compiler flag which generates .di files based on that meaning. 
Correct?

> Stability of (1) headers can be validated mechanically by 
> compiler / external tool in such scenario. As you may notice no 
> new keywords / language concepts are proposed, it is only about 
> more strict definition of standard development flow. It also 
> opens well-defined borderline for any WPO.

If solving the problem at the level of the command line with the 
help of the existing 'export' attribute is more flexible and 
robust, then I'm all for it. The first thing to find out is if 
anyone will have a problem overloading the meaning of 'export' 
for this purpose. I can't think of a reason they would, unless 
people are currently using 'export' in some niche way which would 
be ruined by the new flag.

> Needs a lot of work before any serious destruction of course 
> but should give some overall feeling of what I am going at.

We both agree that full "covariant" inference should be the 
default. It seems like the first step is to introduce it using an 
opt-in compiler flag (e.g. "-infer"). I'm not sure how .di files 
and mangled names should be generated using this flag though. The 
goal is to get the kinks out of the inference process before 
making it the default. What's step two, though?