Async properties in interfaces to cater for the possibility of expensive first-time evaluation: Is this a good idea?

Question

First of all, sorry if this post is too long. I'll start with the…

Short version:

Is it generally advisable or a good idea to design an interface property as asynchronous simply because we cannot be sure whether each and every implementation can guarantee that it's evaluation will be cheap? That is, can it be a good idea to design an interface like this:

interface IFoo
{
    Task<IEnumerable<Bar>> BarsAsync { get; }
}

instead of like this:

interface IFoo
{
    IEnumerable<Bar> Bars { get; }
}

Long version:

Now let me explain how I arrived at this design question.

Let's start with the non-asynchronous version of the interface (shown right above).

Microsoft's framework design guidelines demand that getting the value of a property be cheap; but when we program against an interface, instead of against a particular implementation of IFoo, we cannot be certain that each and every implementation of IFoo that we might be using can and will adhere to that guideline.

What each and every implementation could do is to ensure "amortized cheapness", i.e. cache the property's value upon its first computation, so that at least subsequent accesses will be cheap. Eric Lippert writes in his blog article "When should I write a property?":

A common pattern is for a property to be a cache of an expensive, lazily-computed value […]. Though the property is expensive on its first access, every subsequent access is cheap, so the property is cheap in an amortized sense.

He goes on to suggest using Lazy<T> as an implementation detail towards that end, so let's look at a possible implementation of the above interface where evaluating Bars for the first time would be expensive, but not on subsequent calls:

internal class ExpensiveFoo : IFoo
{
    private readonly Lazy<IEnumerable<Bar>> bars;
    public IEnumerable<Bar> Bars { get { return bars.Value; } }
    public ExpensiveFoo() { bars = new Lazy<IEnumerable<Bar>>(GetBars); }
    private IEnumerable<Bar> GetBars() { … /* some expensive computation */ }
}

What I am wondering at this point is, wouldn't it be better to simply leak the possibility of an expensive first-time evaluation into the interface and change it to:

interface IFoo
{
    Task<IEnumerable<Bar>> BarsAsync { get; }
}

This would allow you to write both "always cheap" implementations as well as "amortized-cheap" implementations (like the above), with the consumer being aware of that fact.

internal class ExpensiveFoo : IFoo
{
    private Lazy<Task<IEnumerable<Bar>>> bars;
    public Task<IEnumerable<Bar>> BarsAsync { get { return bars.Value; } }
    public ExpensiveFoo() { bars = new Lazy<Task<IEnumerable<Bar>>>(GetBarsAsync); }
    private async Task<IEnumerable<Bar>> GetBarsAsync() { … };
}

internal class CheapFoo : IFoo
{
    public Task<IEnumerable<Bar>> BarsAsync { get { return Task.FromResult(bars) } }
    private IEnumerable<Bar> bars;
    public CheapFoo(IEnumerable<Bar> bars) { this.bars = bars; }
}

No matter which implementation gets used, one could then write code that potentially doesn't block even on the first property access:

Foo foo = …;
foreach (Bar bar in await foo.BarsAsync) …

Is this ever a good idea?

Answer 1

One of the reasons properties should never be "fancy" in terms of implementation, is they typically contain code that is executed in the debugger, in the watch windows and other places where variables can be viewed, such as tool tips. Methods are only executed on demand.

Some types of "fancy" properties:

• Those that allocate memory when computing their value.
• Those that do not return in constant time.
• Those that return in constant time, but it is a "long" time (greater than a few milliseconds)
• Those that have side effects: some argue this can be ok if the side effect is to initialize a field lazily. But even this can cause different behavior when attaching a debugger.