Should CacheExtensions.GetOrCreate()/GetOrCreateAsync() return TItem instead of TItem??

[loraderon]

Context: #77266

We just migrated to .NET 7.0 and got bitten by this weird behavior, which forces us to always use the dammit operator.

.NET 6.0

private Task<Foo[]> ListCachedFoo() => await memory.GetOrCreateAsync("foos", async e => await db.ListFoos());

.NET 7.0

private Task<Foo[]> ListCachedFoo() => (await memory.GetOrCreateAsync("foos", async e => await db.ListFoos()))!;

[stephentoub]

This is by design, as the cache supports caching null values. You could write code like:

IMemoryCache cache = ...;
cache.Set(key, (string?)null);
string s = cache.GetOrCreate<string>(key, e => "oops");

and that GetOrCreate call would return null, hence to be correct the API needs to be TItem? rather than TItem.

[loraderon]

I'm actually pretty satisfied with this reasoning even though I would assume that most developers doesn't mix and match between those. But it can't be assumed when there is millions(?) of developers.

I also noticed #48455, and am I correct in assuming that the future version of GetOrCreate equalent returns TItem and not TItem? since the reasoning is gone?

[stephentoub]

Any such method would be a new one rather than changing the existing one. It'd be a significant breaking change to make the existing interface generic, so I don't see that happening. That two-year old issue is just calling out some of the inefficiencies of the existing design, but without solutions.