Potential inliner simplification?

[Nick Sabalausky]

This is something that's been in the back of my mind lately.

First, some background:
------------------------

DMD's inliner makes a very strong distinction between inlining a 
function call as a statement (when no return value is used) vs inlining 
it as an expression (when there is a return value used). The functions 
for inlining the nodes inside function bodies are basically implemented 
twice - once for "as statement" and again for "as expression".

ATM, this duplication appears to be necessary because:

- "Inline as Statement" CANNOT be performed whenever a return value is 
used, since statements don't have return values (only expressions do).

- "Inline as Expression" CANNOT inline functions which use certain types 
of statements, such as (non-unrolled) for loops, because these 
statements are not expressible as expressions.

So this duplication maximizes the chances a function call is inlinable.

My reasoning:
--------------

However, all those restrictions (and consequently, the need for separate 
"as expression" vs "as statement" codepaths) are forced by one reason: 
DMD's AST doesn't support expressions that contain statements.

That seems natural since the D language itself doesn't allow statements 
to be used as expressions. However, that doesn't mean the AST can't 
*internally* support them.

Proposal:
----------

If DMD added a new subclass of Expression, say "StatementExp" 
(essentially a reverse counterpart of "ExpStatement"), then, at least in 
theory, all the "Inline as Statement" vs "Inline as Expression" could be 
merged into one unified set:

Any statement that D cannot normally support as an expression could be 
converted to an expression by placing it inside a StatementExp. Thus, 
the entire "inline as a statement" portion of the inliner could be 
eliminated since the "as an expression" branch alone would be powerful 
enough to handle all cases.

My questions:
--------------

A. Is this reasoning even valid in the first place?

B. Are there enough untapped future enhancements remaining in the 
inliner for this to actually be worthwhile at all?

C. How much trouble would adding a "StatementExp" cause for the various 
backends? I don't know anything about how the backend(s) handle DMD's 
AST or what would even be involved in supporting a new node type.