On 09/27/15 13:48, Marco Leise via Digitalmars-d wrote: > Am Sat, 26 Sep 2015 19:58:14 +0200 > schrieb Artur Skawina via Digitalmars-d > <digitalmars-d@puremagic.com>: > >> `allow` is the default state and always safe; for the cases >> where it's /undesirable/, there is noinline. > > No what I meant was when the compiler sees inline assembly or > anything else it deems not safe to inline, you can convice it > anyways. It is more like @trusted on otherwise @system > functions. I just mentioned it so it is under consideration, > as I have seen it in LLVM.
The problem with this would be that it would soon lead to a C-like mess -- a lot of function marked with `allow` just-in-case. Failure to inline is a compiler implementation problem, it shouldn't affect the language, which already has enough annotation noise. What would be the cases for `allow`, that are /not/ caused by compiler limitations? (dmd's legacy inline asm hack is not part of the language in practice, so that does not count) Also keep in mind that `noinline` will often not come alone, but be accompanied by other annotations like `noclone`. `noinline` often means that the functions identity matters, so you have to disable cross-function constant propagation etc too. It can all be done by bundling the attributes via alias, but the defaults must be sane, so that most code does not need annotations (for example: a templated function containing a mixin must not require @inlinable @clonable @etc just because the mixed in code, that is not locally known, /might/ silently turn off inlining). artur