On Tuesday, April 19, 2016 03:27:46 Marco Leise via Digitalmars-d wrote: > 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!
Except that unfortunately, the compiler _does_ do attribute inference for auto return functions now, because the body is guaranteed to be available. Relying on that inference in a public API that's part of a library will easily lead to code breakage when the function implementation is changed (or even when a function that it calls is changed, if that affects its attributes). Personally, I think that adding attribute inference for auto return functions was a mistake and just encourages bad practices, but unless Walter can be convinced that it was such a bad idea that it needs to be reverted (and break whatever code thatt that would break), we're stuck with it. Regardless, I think that it's clear that if you want a stable API, you need to infer attributes as little as possible. > 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. Isn't that basically what folks like Benjamin and Martin want the export keyword to do? - Jonathan M Davis
