H1 2015 Priorities and Bare-Metal Programming

[Mike via Digitalmars-d]

On Tuesday, 3 February 2015 at 09:36:57 UTC, Walter Bright wrote:
> On 2/3/2015 1:11 AM, Mike wrote:
>> All things being equal, will there be any difference between 
>> the resulting
>> binaries for each of these scenarios?
>
> No.
>
>> Another way of putting it:  Does pragma(inline, true) simply 
>> allow the user to
>> compiler parts of their source file with -inline?
>
> Yes.
>
> I'm beginning to think a pragma(hot, true/false) might be a 
> better approach, as there are more optimizations that can be 
> done better if the compiler knows which branches are hot or not.

I believe both sides in this debate are actually right, but I'm 
siding with Walter:  pragma(inline, true) should not generate a 
compiler error if a function cannot be inlined.

The expressed need by the other side is right on, and that need 
should have be acknowledged.  However, I believe that is a need 
that Walter did not intend to address with DIP56.

IMO, the important thing to explain in DIP56 is the relationship 
pragma(inline) has to the -inline compiler flag, and that it is 
not a substitute for future features that may provide strict 
enforcement.

It may even be better, and less controversial, to have a 
pragma(compiler, "-inline -whatever") that gives the user more 
fine control over, not just -inline, but other compiler options 
as well...and each compiler flag should have a negative (e.g. 
-no-inline) conterpart.

I don't like "hot/cold" as it does not convey the effect.

Mike