On attribute inference...

[Marco Leise via Digitalmars-d]

Currently the compiler makes sure, that it can see the entire
nested call chain when performing attribute inference. So it
limits itself to function literals and templates where the
source has to be right there for them to compile.

The remaining functions could roughly be classified as
functions that could reside in an external lib with only the
headers and no source being available.

But even so, the external functions will encode their
attributes into the mangled name and linking is impossible
without knowing them. Where do we find this information? In
the .di files, where they must have been inferred by the
header generator.

So external functions without bodies declare their attributes
_explicitly_ and they are a de-facto part of a library's API
due to the mangling.

This means that the compiler must not infer attributes on
functions which could be part of a library API and here is why:
Imagine what would happen if it inferred @nogc and you didn't
realize that. If later on you change the code to allocate
something, @nogc is magically revoked and you have yourself an
API breakage!

Anyone who is arguing for more attribute inference must be
aware of this. Whatever the Dlang spec says about "function
body availability" is misleading, because the real motivation
is forcing people to be explicit about their public APIs.

No case makes the distinction between "function body
availability" and "API stability" more clear than auto return.
Even though their source code is copied verbatim into the .di
files to allow the return of voldemort types (i.e. types that
are defined inside the function returning it), their
attributes are *not* inferred, because they may be part of a
public API!

Let's get into that "public API" mindset. We need to use .di
files for libraries or else the compiler will transitively
analyze every imported .d file from your project and any used
libraries. Imagine how much source code a project like
LibreOffice and all dependent libraries comprises! That does
not scale. I'd also propose a visibility level above 'public',
to tag symbols that are exported from a library. All others
are not invisible in .dll/.so files and removed during .di
generation. All functions that are not part of such "exported"
symbols can then have their attributes inferred.

Gains:
 + Attribute inference on all private API!
 + Faster compiles: .di files short circuit recursive imports!
 + Solves bugs!: https://issues.dlang.org/show_bug.cgi?id=9816

Ok, so who writes a DIP for this? Benjamin Thaut, Martin
Nowak and David Nadlinger: http://wiki.dlang.org/DIP45

-- 
Marco