properties - Problems with adding a `lazy` keyword to C# -

i love write code this:

class zebra {     public lazy int stripecount     {         { return expensivecountingmethodthatreallyonlyneedstoberunonce(); }     } } 

edit: why? think looks better than:

class zebra {     private lazy<int> _stripecount;      public zebra()     {         this._stripecount = new lazy(() => expensivecountingmethodthatreallyonlyneedstoberunonce());     }      public lazy int stripecount     {         { return this._stripecount.value; }     } } 

the first time call property, run code in get block, , afterward return value it.

my questions:

1. what costs involved adding kind of keyword library?
2. what situations problematic in?
3. would find useful?

i'm not starting crusade next version of library, curious kind of considerations feature such should have go through.

i curious kind of considerations feature such should have go through.

first off, write blog subject, amongst others. see old blog:

http://blogs.msdn.com/b/ericlippert/

and new blog:

http://ericlippert.com

for many articles on various aspects of language design.

second, c# design process open view public, can see language design team considers when vetting new feature suggestions. see roslyn.codeplex.com details.

what costs involved adding kind of keyword library?

it depends on lot of things. there are, of course, no cheap, easy features. there less expensive, less difficult features. in general, costs involving designing, specifying, implementing, testing, documenting , maintaining feature. there more exotic costs well, opportunity cost of not doing better feature, or cost of choosing feature interacts poorly future features might want add.

in case feature making "lazy" keyword syntactic sugar using lazy<t>. that's pretty straightforward feature, not requiring lot of fancy syntactic or semantic analysis.

what situations problematic in?

i can think of number of factors cause me push on feature.

first off, not necessary; it's merely convenient sugar. doesn't add new power language. benefits don't seem worth costs.

second, , more importantly, enshrines particular kind of laziness language. there more 1 kind of laziness, , might choose wrong.

how there more 1 kind of laziness? well, think how implemented. properties "lazy" in values not calculated until property called, want more that; want property called once, , value cached next time. "lazy" mean memoized property. guarantees need put in place? there many possibilities:

possibility #1: not threadsafe @ all. if call property "first" time on 2 different threads, can happen. if want avoid race conditions, have add synchronization yourself.

possibility #2: threadsafe, such 2 calls property on 2 different threads both call initialization function, , race see fills in actual value in cache. presumably function return same value on both threads, cost here merely in wasted call. cache threadsafe, , doesn't block thread. (because threadsafe cache can written low-lock or no-lock code.)

code implement thread safety comes @ cost, if low-lock code. cost acceptable? people write single-threaded programs; seem right add overhead of thread safety every single lazy property call whether it's needed or not?

possibility #3: threadsafe such there strong guarantee initialization function called once; there no race on cache. user might have implicit expectation initialization function called once; might expensive , 2 calls on 2 different threads might unacceptable. implementing kind of laziness requires full-on synchronization possible 1 thread blocks indefinitely while lazy method running on thread. means there deadlocks if there's lock-ordering problem lazy method.

that adds more cost feature, cost borne equally people not take advantage of (because writing single-threaded programs).

so how deal this? add 3 features: "lazy not threadsafe", "lazy threadsafe races" , "lazy threadsafe blocking , maybe deadlocks". , feature got whole lot more expensive , way harder document. produces enormous user education problem. every time give developer choice this, present them opportunity write terrible bugs.

third, feature seems weak stated. why should laziness applied merely properties? seems applied through type system:

lazy int x = m(); // doesn't call m() lazy int y = x + x; // doesn't add x + x int z = y * y; // m() called once , cached.                // x + x computed , cached                // y * y computed 

we try not small, weak features if there more general feature natural extension of it. we're talking serious design , implementation costs.

would find useful?

personally? not useful. write lots of simple low-lock lazy code using interlocked.exchange. (i don't care if lazy method gets run twice , 1 of results discarded; lazy methods never expensive.) pattern straightforward, know safe, there never objects allocated delegate or locks, , if have little more complex can use lazy<t> work me. small convenience.