On 19 March 2014 19:16, <[email protected]>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.
