Overloading Lazy Vs. Non-Lazy

[Steven Schveighoffer]

On Wed, 11 Aug 2010 09:19:01 -0400, dsimcha <dsimcha at yahoo.com> 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.

Hold on, can't we have enforce and lenforce (lazy enforce)?

 From a simple grep, 99% of enforce instances are:

enforce(condition)
  -or-
enforce(condition, "compile-time-string")
  -or-
enforce(condition, "compile-time-string" ~ type.stringof)

There are a few ones which actually would be allocating strings at  
runtime, but seriously, can't we just modify those to lenforce and get  
inlining everywhere else?  I think phobos would see both a huge speedup  
and a smaller footprint immediately if enforce did not take a lazy arg.

-Steve