Overloading Lazy Vs. Non-Lazy

[Brad Roberts]

On 8/11/2010 6:19 AM, dsimcha wrote:
> An issue that's come up here several times before is that enforce()
> effectively disables inlining of the function it's used in.  From reading some
> disassemblies, the reason seems to be because of all the ASM code that's
> required for lazy parameters.  I wonder if either of the following is feasible:
> 
> 1.  When a function takes a lazy parameter, the compiler automatically
> generates two versions under the hood:  One that actually takes a non-lazy
> parameter and is used when the value is known at compile time and another that
> works like current lazy functions.  The only problem here is that this might
> create issues when using function pointers/delegates.
> 
> 2.  Allow overloading of lazy and non-lazy functions, with the rule that the
> lazy version gets called whenever the value must be computed at runtime and
> the non-lazy version gets called if the value is statically known and thus
> there's no evaluation to speak of.

It's the throw that blocks inlining right now.  Lazy might also disable inlining
too, I haven't looked for that case.  Either way, that's purely a quality of
implementation issue.  I don't think it'd be a good idea to bend the library all
that much to work around that kind of limitation.  It's something that will get
better as time permits.

Later,
Brad