On 19 March 2014 16:18, <7d89a89974b0ff40.invalid@internationalized.invalid> wrote:
On Wednesday, 19 March 2014 at 01:28:48 UTC, Manu wrote:
In the case you do want to inline the whole tree, you can just cascade the
mixin through the stack. In the case you suggest which flattens the tree by
default, we've lost control; how to tell it only to do it for one level
without hacks? And I believe this is the common case.

You could provide it with a recursion level parameter or parameters for cost level heuristics.

Again, I think this is significantly overcomplicating something which see is being extremely simple.

It could also be used to flatten tail-call recursion.

I don't think it's valid to inline a tail call recursion, because the inlined call also wants to inline another call to itself...
You can't know how fer it should go, so it needs to be transformed into a loop, and not we're talking about something completely different than inlining.

As the one that requested it, I have numerous uses for it to mixin just the
one level. I can't imagine any uses where I would ever want to explicitly
inline the whole tree, and not be happy to cascade it manually.

In innerloops to factor out common subexpressions that are otherwise recomputed over and over and over.

This is highly context sensitive. I would trust the compiler heuristics to make the right decision here.
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. And I personally wouldn't depend on a feature such as this to address that sort of a problem in my codegen. I would just refactor the function a little bit to call the common sub-expression ahead of time.

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

I'm not sue what you mean here?

noninline_func(){ inline_func();}


Why? This is really overcomplicating a simple thing. And I'm not quite sure
what you're suggesting this should do either. Are you saying the call tree
is flattened behind this proxy non-inline function?

No, I am saying that the one level mixin doesn't provide you with anything new.

It really does provide something new. It provides effectively, a type-safe implementation of something that may be used in place of C/C++ macros. I think that would be extremely useful in a variety of applications.

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. GDC/LDC offer attributes, but then it's really annoying that D has no mechanism to make use of compiler-specific attributes in a portable way (ie, attribute aliasing), so I can't make use of those without significantly interfering with my code.

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.