DIP56 - inlining

[Zach the Mystic via Digitalmars-d]

On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright 
wrote:
> On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
>> On 2/4/15 4:02 AM, Walter Bright wrote:
>>> On 2/4/2015 1:39 AM, ponce wrote:
>>>> Would pragma(inline, <bool-expr>) be supported though?
>>> Yes. That's what I intended, sorry the wording wasn't clear.
>> Please nail it down in the doc so it doesn't get neglected. -- 
>> Andrei
>
> Reading the DIP again,
>
> "This adds a pragma 'inline', which is followed by an optional 
> boolean expression, which influences the inlining of the 
> function it appears in. An evaluation of 'true' means always 
> inline, 'false' means never inline, and no argument means the 
> default behavior."
>
> Seems clear enough.

Also, the "Rationale" seems outdated now too. Currently: 
"Sometimes generating better code requires runtime profile 
information. But being a static compiler, not a JIT, the compiler 
could use such hints from the programmer."

I would change that rationale to this one (feel free to confirm 
and/or copy): "Programmers will sometimes want precise control of 
the compiler's inlining behavior, either to improve performance 
in debug builds, or to be completely sure that a function is 
inlined, or to ensure access to the function's runtime profiling 
information by not inlining it. This DIP addresses those needs. 
Warning: Careless forcing of inlining can decrease performance 
dramatically. Use with caution."

Also, speaking of hints to the compiler:

pragma(hotcodepath, true/false);

... seems really interesting to me, although that's clearly the 
subject for a different DIP. I just wanted to emphasize that the 
current DIP is not meant to address that feature.