On 19 March 2014 19:16, <7d89a89974b0ff40.invalid@internationalized.invalid> wrote:
On Wednesday, 19 March 2014 at 08:35:53 UTC, Manu wrote:
The idea of eliminating common sub-expressions suggests that there _are_
common sub-expressions, which aren't affected by the function arguments.
This case is highly unusual in my experience.

Not if you delay optimization until profiling and focus on higher level structures during initial implementation. Or use composing (like generic programming).

If you hand optimize right from the start then you might be right, but if you never call a function with the same parameters then you are doing premature optimization IMHO.

Okay, do you have use cases for any of this stuff? Are you just making it up, or do you have significant experience to say this is what you need?
I can say for a fact, that recursive inline would make almost everything I want it for much more annoying. I would find myself doing stupid stuff to fight the recursive inliner in every instance.

When the function is generated code (not hand written).

I'm not sue what you mean here?

Code that is generated by a tool (or composable templates or whatever) tend to be repetitive and suboptimal. I.e. boiler plate code that looks like it was written by a monkey…

I'm not sure where the value is... why would you want to inline this?

You already have that. It is sugar.


I don't already have it, otherwise I'd be making use of it. D has no control over the inliner.

I meant that if you have explicit inline hints like C++ then you also have call-site inlining if you want to.

I still don't follow. C++ doesn't have call-site inlining. C/C++ has macros, and there is no way to achieve the same functionality in D right now, that's a key motivation for the proposal.

I also don't think that suggestion of yours works. I suspect the compiler
will see the outer function as a trivial wrapper which will fall within the
compilers normal inline heuristics, and it will all inline anyway.

That should be considered a bug if it is called from more than one location.

Seriously, you're making 'inline' about 10 times more complicated than it should ever be.
If you ask me, I have no value in recursive inlining, infact, that would anger me considerably.

By making this hard, you're also making it equally unlikely. Let inline exist first, then if/when it doesn't suit your use cases, argue for the details.