Proposal: Automatic getter-properties with expression bodies should get some syntax for caching.

[AdmiralSnyder]

Problem

when implementing a property that should get cached using an expression body, you need to produce a redundant backing field:

class MyClass
{
  bool Prop1AlreadyCalculated = false;
  int _Prop1; // backing field
  int Prop1 => Prop1AlreadyPopulated? _Prop1 : _Prop1 = CalculateProperty();
}

the Lazy class helps here:

class MyLazyClass
{
  Lazy<int> _Prop1 = new Lazy<int>(() => CalculateProperty()); // backing lazy field
  int Prop1 => _Prop1.Value;
}

but this is not useful if CalculateProperty() isn't static. you cannot access instance members in initialization code. So either we are back to:

class MyLazyClass
{
  Lazy<int> _Prop1; // backing lazy field, still null.
  int Prop1 => (_Prop1 ?? (_Prop1 = new Lazy<int>(() => CalculateProperty())).Value;
}

... which makes the notion of a lazy redundant, or putting the instanciation of the lazy into the constructor, which destroys locality, and makes it neccessary to have a third place and second time that we have to do initialization for our property.

My suggestion

Add a context-specific keyword "value" to the property getter expression:

class MyLazyClass
{
  int Prop1 => value = CalculateProperty();
}

a getter expression that's an assignment to value will only be fetched once, because the fact that the initalization has occured is remembered; value could be backed by an implicit lazy backing field.

[MkazemAkhgary]

problem with your syntax is value in that context can be a valid identifier. so it cant be context specific keyword. there is no need for such syntax however.

here is alternative way.

int? _Prop1; // backing field
int Prop1 => _Prop1 ?? (_Prop1 = CalculateProperty()).Value;

[bondsbw]

value could be backed by an implicit lazy backing field

This is similar to proposals #133 and #140.

a getter expression that's an assignment to value will only be fetched once, because the fact that the initalization has occured is remembered

This isn't obvious from the syntax. I think it would be confusing to have completely different behavior between these scenarios:

int Prop1 => value = CalculateProperty();  // Cached
int Prop2 => val = CalculateProperty();    // Evaluated every time

[yaakov-h]

There are a couple proposals on this already, but in the meantime does LazyInitializer.EnsureInitialized solve your non-static problem?

[VanKrock]

class MyLazyClass
{
  int Prop1 => lazy CalculateProperty();
}

[MkazemAkhgary]

@VanKrock ok if you want keyword just go ahead

lazy int Prop1 => ...;

[yaakov-h]

#312 and #681 have discussed this extensively already.

In particular, I find this to be the neatest solution so far: #681 (comment)

[AdmiralSnyder]

the idea is to reduce the number or artifacts in the source file that has to be written to implement a cached property to one, ideally without having to write too much noise, and without the client of the class needing to know that the property is cached.

@MkazemAkhgary and @bondsbw : I thought of the value keyword because it is used in setters, so developers are familiar with it, and - just like in setters - it shadows existing members named value, making them inaccessible in the setter right now, so using it in the getter, too doesn't seem to be a problem. if you want to protect the case where there are existing getters that do access a field or property named value, some opt-in setting combined with an analyzer could work.

[AdmiralSnyder]

@yaakov-h LazyInitializer.EnsureInitialized not only requires an explicit backing field declaration but also (if null is allowed or we have a value type) to even a third field to remember the initialization.

I initially played around with a caching class that led to a syntax like this:
public string Prop1 => Cache.Lookup(this, (t) => Calculate()/, "Prop1" provided by CallerNameAttribute/);
but since i cannot be notified when an object gets GCed, i end up with dangling uncollected Cached values when using WeakReferences and uncollectable class instances when not :-(

// corrected typo. thanks @VanKrock

[yaakov-h]

@AdmiralSnyder "third field"? EnsureInitialized only needs 3 if you also want to specify an explicit sync root object.

You could try ConditionalWeakTable for your caching class if you really really wanted 😈

[VanKrock]

@AdmiralSnyder

public string Prop1 => Cache.Lookup(this, Calculate()/, "Prop1" provided by CallerNameAttribute/);

Calculate() called for every call Prop1. Use Func:

 () => Calculate();

public string Prop1 => Cache.Lookup(this, () => Calculate()/, "Prop1" provided by CallerNameAttribute/);

[VanKrock]

@MkazemAkhgary
lazy int Prop1 => ...; When call Prop1 we want to get int, no difference it's lazy or not. It's implementetaion details.

[AdmiralSnyder]

@yaakov-h this seems to be exactly what i need for the Cache class. Didn't know about that. thanks so much.

[MkazemAkhgary]

@VanKrock lazy is not part of the signature, any way having keyword for such unique use case seems overkill.

There are already good solutions provided. no need for new keyword.

[AdmiralSnyder]

i got it down to
string Prop => Cache.Fetch(this, (t) => Calculate(t));
or
string Prop => this.FetchCached(Calculate); // as extension method
with reasonable performance, at least for reference types. maybe this is sufficient...

[jnm2]

Using a backing field without naming it was considered in https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-04-01.md