Prototype DIP11

[Jonathan M Davis]

On Monday, August 15, 2011 01:32:02 Martin Nowak wrote:
> On Mon, 15 Aug 2011 01:19:29 +0200, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On Monday, August 15, 2011 01:12:20 Martin Nowak wrote:
> >> I've implemented a prototype of the DIP11 draft.
> >> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
> >> https://github.com/dawgfoto/dmd/tree/DIP11
> >> 
> >> -- Restrictions --
> >> 
> >>   - It doesn't check for conflicting qualified imports
> >>   (-Iacme=/path1
> >> 
> >> -Iacme.a=/path2)
> >> 
> >>   - pragma(importpath, "<import-path>") must come lexically before
> >>   the
> >> 
> >> import
> >> 
> >>   - Untested on Windows
> >> 
> >> -- Some outcome --
> >> 
> >>   - Using '=' in [module.or.package=]<path-or-url> could be slightly
> >> 
> >> ambiguous for '-Ihttp://acme.org?format=raw'.
> >> 
> >>   - Url syntax collides with import path lists. Currently it is
> >>   allowed
> >> 
> >> to
> >> specify -I/path1/import:/path2/import for POSIX. I've deactivated that
> >> for
> >> now.
> >> 
> >>     Both can be disambiguated so they are not very severe.
> >>   
> >>   - Using 'pragma(lib, "someLib")' in an imported source has no
> >>   effect,
> >> 
> >> as
> >> long as the imported module is not compiled.
> >> 
> >>   - Overall this is very limited as even the example below will only
> >> 
> >> compile up to a linker error.
> >> 
> >> -- Testing --
> >> 
> >>   - build dmd from DIP11 branch
> >>   - get download.py: http://codepad.org/XAvSN505
> >>   - get test.d: http://codepad.org/BILAwzHj
> >>   - add 'DOWNLOADTOOL= path/to/download.py' to your /etc/dmd.conf
> >>   - compile: dmd test.d
> >> 
> >> -- Brainstorming --
> >> We need to define a compilation model for the imported files.
> >> 
> >> One solution could be to generally change the semantics of importing
> >> to
> >> mean if the
> >> imported file is a source (*.d) build an object for that module if it
> >> is a
> >> header (*.di) don't
> >> build an object and leave it to the user to supply binary data.
> > 
> > That's not going to work. That assumes that libraries use .di files,
> > which
> > isn't necessarily true. If a library just uses .d files, then that means
> > that
> > you're recompiling modules from the library when you don't need to (and
> > probably shouldn't be since, I would expect that you'd end up with
> > complaints
> > about symbols being defined twice when you link in the library).
> > 
> > - Jonathan M Davis
> 
> Yes I'm aware of this. Prominent example being phobos vs. druntime.
> But the idea was exactly to change this (in the long-term/opt-in).
> Requiring libraries to be bundled with .di files.

That's just not going to work. If you use .di files, you lose CTFE and inlining 
for anything which isn't in the .di files. As such, there's a definite advantage 
for a library to _not_ use .di files. There have been some suggestions about 
how to fix that, but it's pretty much been decided to put off fixing how .di files 
to D3.

So, libraries _must_ be able to use .d files exclusively. With D2, we _cannot_ 
assume that libraries will use .di files. There's a good chance that they 
won't. Maybe they will for D3 but not for D2.

- Jonathan M Davis