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