Overloading Lazy Vs. Non-Lazy
Steven Schveighoffer
schveiguy at yahoo.com
Thu Aug 12 04:47:08 PDT 2010
On Thu, 12 Aug 2010 02:00:00 -0400, Brad Roberts <braddr at puremagic.com>
wrote:
> 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.
Well, there's something to be said about preventing the bloated generation
of code that accompanies lazy.
But throwing preventing inlining is a bad one, that should be fixed.
-Steve
More information about the Digitalmars-d
mailing list