inlining or not inlining...

[so]

> How many times do I need to repeat I do not want to force inlining? Or  
> what else are you talking about?

And this is why it doesn't make sense.
What are we doing here? Are we trying to find practical solutions to real  
world problems or just showing how useless things D can do?

> Instead, I want to /know/. Example use: ensure trivial externalisation  
> dist below will be properly inlined back by the compiler. I factorise  
> out dist for code clarity, but do not want this to cause stupid  
> performance penalty. Cases:
> * the compiler shut up --> ok
> * the compiler says 'no' -- possibly 'because ...'
>      ~ I can decide to unfactor out
>      ~ I can measure, and realise cost of func call is nothing compared  
> to square root

Listen, inlining is not something to play with like that, you either want  
a function to be inlined or not, this simple.
The reasons are straightforward. Say you have an intersection test where  
you optimized and such, it might contain square roots, dots, crosses  
whatever and nothing you can do about it anymore.
It is obviously costly, costs far more than the function call cost. So  
far, everything as usual, compiler free to do what it believes right. But  
you know beforehand this block of code will run in many loops which  
changes the scenario, now function call is an issue. You don't care if  
compiler did it or not, you simply want it to be done.

>      ~ I may learn something from additional info

Which will serve no purpose!

>      ~ I may realise the case is not as trivial as it seems

Which again surves no purpose unlike you want it to be done.

> // billions of them
> struct Point {
>      float x,y;
>      float d;
>      this (float x, float x) {
>          this.x = x;
>          this.y = y;
>          // inline or not inline?
>          this.d = dist(x,y);
> pragma (inlineinfo) {
>      static float dist (int x, int y) {
>          return squareRoot(x*x + y*y);
>      }
> }
> }

If in your program flow,
. this struct is to be used frequently
. performance is your primary concern,
. you have no other things to worry about (algorithms, other optimizations)
. you know if inlining is a gain.

Then you know beforehand that function should be inlined or not, otherwise  
knowing that has no purpose whatsoever.