<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 19 March 2014 19:16,  <span dir="ltr"><<a href="mailto:7d89a89974b0ff40.invalid@internationalized.invalid" target="_blank">7d89a89974b0ff40.invalid@internationalized.invalid</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Wednesday, 19 March 2014 at 08:35:53 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The idea of eliminating common sub-expressions suggests that there _are_<br>
common sub-expressions, which aren't affected by the function arguments.<br>
This case is highly unusual in my experience.<br>
</blockquote>
<br></div>
Not if you delay optimization until profiling and focus on higher level structures during initial implementation. Or use composing (like generic programming).<br>
<br>
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.<br></blockquote><div><br></div><div>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?</div>
<div>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.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When the function is generated code (not hand written).<br>
</blockquote>
<br></div><div class="">
I'm not sue what you mean here?<br>
</div></blockquote>
<br>
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…<br></blockquote><div><br></div><div>I'm not sure where the value is... why would you want to inline this?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You already have that. It is sugar.<br>
<br>
</blockquote>
<br></div><div class="">
I don't already have it, otherwise I'd be making use of it. D has no control over the inliner.<br>
</div></blockquote>
<br>
I meant that if you have explicit inline hints like C++ then you also have call-site inlining if you want to.</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also don't think that suggestion of yours works. I suspect the compiler<br>
will see the outer function as a trivial wrapper which will fall within the<br>
compilers normal inline heuristics, and it will all inline anyway.<br>
</blockquote>
<br></div>
That should be considered a bug if it is called from more than one location.<br>
</blockquote></div><br></div><div class="gmail_extra">Seriously, you're making 'inline' about 10 times more complicated than it should ever be.</div><div class="gmail_extra">If you ask me, I have no value in recursive inlining, infact, that would anger me considerably.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
</div>