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

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.

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

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?

On Friday, 9 January 2015 at 16:14:01 UTC, Zach the Mystic wrote:
> 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.

This DIP is of relevance:
http://wiki.dlang.org/DIP45

Very interesting, looking forward to reading the DIP.

Atila

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.
> - .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).
>
> 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.
>
> Needs a lot of work before any serious destruction of course but should give some overall feeling of what I am going at.

On Saturday, 10 January 2015 at 10:47:04 UTC, Marc Schütz wrote:
> On Friday, 9 January 2015 at 16:14:01 UTC, Zach the Mystic wrote:
>> 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.
>
> This DIP is of relevance:
> http://wiki.dlang.org/DIP45

Yes, it was partly what started me thinking in this direction, DIP45 is very wise.

On Friday, 9 January 2015 at 16:14:01 UTC, Zach the Mystic wrote:
> 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?

It is not truly overloading with new meaning. One can argue that existing meaning of export can already be interpreted that way, it is simply not implemented in full power. See DIP45 for some more stuff on topic.

As for the rest - I'd better try answering those questions if I ever sit down and actually write it carefully, right now it is more like bunch of vague ideas rolling around with no solid structure.

I've now created DIP70 for this issue:

http://wiki.dlang.org/DIP70

Maybe a more sophisticated linking mechanism will make DIP70 unnecessary, but it should fuel the discussion nonetheless. Also, the wiki refused all of my attempts to insert the following links, saying they were non-canonical, despite my following the instructions on the help page:

LINK1 (this thread):
http://forum.dlang.org/thread/vlzwhhymkjgckgyoxlrq@forum.dlang.org

LINK2 (Dicebot's proposal):
http://forum.dlang.org/post/otejdbgnhmyvbyaxatsk@forum.dlang.org

Please edit the wiki to correct this if you can.