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
