H1 2015 Priorities and Bare-Metal Programming

[Walter Bright via Digitalmars-d]

On 2/3/2015 1:56 AM, Daniel Murphy wrote:
> I don't expect this to be a huge problem, because most functions marked with
> forceinline would be trivial.
>
> eg. setREG(ubyte val) { volatileStore(cast(ubyte*)0x1234, val); }
>
> This function only exists to give a nicer interface to the register.  If the
> compiler can't inline it, I want to know about it at compilation time rather
> than later.
>
> Again, it's for those cases that would just be done with macros in C.  Where the
> code should always be inlined but doing it manually the source would lead to
> maintenance problems.

To not inline trivial functions when presented with forceinline would indeed be 
perverse, and while legally possible as I've said before no compiler writer 
would do that. Even dmd (!) has no trouble at all inlining trivial functions.

But the trouble is, people will use forceinline on very non-trivial functions, 
and functions where it would actually make things worse, etc., and then to have 
the compiler error out on them would not be productive.

See the Rust link I provided on experience with the use and misuse of forceinline.