Lazy<T> Optimized Resource Initialization

The Discussion

• 

  This looks like the "once" construct in Eiffel coupled with locking code for thread-safety.

   

  It would be somewhat interesting to be able to do something like this

   

  [Lazy] public int Expensive { get { return InsanelyExpensive(); } }

   

  where the compiler will use the attribute to modify the code to use Lazy<int> underneath. This will make the laziness completely transparent to the caller, the transformed code will be something like this

   

   public class LazyOrNot { private static T Slow<T>(T x) // why does this need to be static? { System.Threading.Thread.Sleep(3000); return x; } public int LetsPlay1 { get { return Slow(42); } } private Lazy<int> lazy = new Lazy<int>(()
   => Slow(42)); public int LetsPlay2 { get { return lazy.Value; } } [Lazy] public int LetsPlay3 { get { return LetsPlay1; } } } 

   

  Many interesting things possible...

   

  Actually, I wonder if Lazy is the right name, given that a method is also "lazy" until evaluated but it does not memoize its result which is what this construct does I presume: evaluate once and remember, just like the Eiffel "once" (maybe Memo<T>; but Lazy<T> is more easily understood, probably)

• 

  What's the hype with the "lazy" word ?

  Why not use "Cached" so everybody would understand it ?

   

  Exoteric: why not as a keyword ?

  public lazy int Expensive { get; }

  public lazy int SomeMethod() { ... }   // so it's only called once

• 

  Is there a way to invalidate the "cached" value ?

  What happen when we use it with a deferred LINQ query ?

• 

  I think this is great

  thanks,

  Pencils

• 

  How I love our developer community.

   

  You're right on the money -- lazy language integration would be sweet, so sweet in fact, that F# has it.   As for C#, it's certainly something that the C# team has and would considered but it takes a lot of effort and a lot of vetting to get a new feature into a language.  The type hasn't even been RTMed yet!  That said, the C# team always loves feedback and feature requests:

   

  Go to https://connect.microsoft.com/VisualStudio?wa=wsignin1.0, click "Submit Feedback for VS2010, then click "Submit a Suggestion"

   

  Josh

• 

  ramoon,

   

  Lazy is a pretty well-known CS concept and "Cached" doesn't seem to capture the most important function of the type -- you can have something that's eagerly evaluated and cached as well. 

   

  There is no way to invalidate a specific Lazy<T> instance.  We wanted Lazy<T> to be as observationally pure as possible and behave just as if it were any other variable.  For example, in C#, if you can't create an int of 4 and then invalidate it -- you simply reassign it.  The same goes for a Lazy<int>. 

   

  As for LINQ query, I'm not sure I understand the question.. When you use a Lazy<T> in a LINQ or PLINQ query, it will be evaluated whenever the execution occurs Value is called.

   

  Hope that helps!

   

  Josh

• 

  Actually, not having implemented attributes myself, I assumed that you could create a C# attribute and setup a code transformation "pipeline" (chained attributes?) to transform the source code into something where the function is memoized, but I guess this is something the C# team is investigating. I'd rather have that than another keyword.

   

  It reminds me of D where you can do compile-time function execution and string manipulation (actually you could build a compile-time parser that builds an AST, does code-transformation and outputs the transformed source code, all at compile-time). C# would hopefully let you do that directly. Well, it's not *that* important, just interesting.

   

  This Lazy type is very nice and I'll probably be using it here and there. In a similar fashion I made the Unnullable type but I think it would be cool if somehow these types could cloak themselves as their nested types so you didn't "see" them - but that would require compiler support as above.

• 

  Whoa! We'll be able to clean up a lot of our code.  We currently have that pattern all over the place.

• 

  so, in MEF there is a Lazy<T,TMetadata> will that go into the bcl as well?

   

  also, it would really be helpful to have implicit operators between Lazy<T> and T

• 

  Hi aL_,

   

  Lazy<T,TMetadata> actually extends Lazy<T> and no it won't end up in BCL, for Beta 2, it's actually in System.ComponentModel.Composition.  We'd considered the implicit cast operator but because we're executing arbitrary code we determined that's a bad idea.  It's only complicated by the fact that the valueFactory delegate may thrown an exception.

   

  Thanks for the feedback!

   

  Josh