Proposal: Create `interface IClaimDeferral`/'abstract class Deferral` and apply to every class providing GetDeferral() method

[SetTrend]

Proposal:

In order to homogenize deferrals, I suggest to create a new, distinct pair of interface IClaimDeferral and abstract class Deferral. (The names I use here are merely suggestions.)

Apply these to every class providing a GetDeferral() method instead of retaining the literally hundreds of strayed, distinct implementations for the same kind of functionality.

Summary

I propose to create a new interface IClaimDeferral and have it being implemented by all classes providing a GetDeferral() method. The return value should return an object deriving from an abstract base class Deferral:

interface IClaimDeferral
{
  Deferral GetDeferral();
}


abstract class Deferral : IDisposable
{
  public virtual void Complete()
  {
    ...
  }

  public void Dispose() => Complete();
}

Rationale

It's currently quite tedious and error-prone to encompass almost each and every awaiting method implementation with:

var deferral = e.GetDeferral();

...

deferral.Complete();

I anticipate significant ease of implementation by replacing the current plethora of divergent GetDeferral() implementations and return values by using a vanilla, single, homogenous implementation that's utilizing the IDisposable pattern.

The most significant simplification I can think of right away would be to use a using declaration to have the deferral's Complete() method called automatically:

void My_Event(object sender, SomeEventArgs e)
{
  using e.GetDeferral();

  ...
}

// having SomeEventArgs extend Deferral, like:
public class SomeEventArgs : Deferral
{
  ...
}

---

Second Thought

I'm not sure, but is it truly necessary to bother programmers with deferrals anyway?

When the UWP runtime triggers an event, instead of using event arguments providing a GetDeferral() method, why doesn't the runtime itself simply claim a Deferral and close it afterwards?

var d = new Deferral();

await _myEvent?.Invoke(this, ea);  // pseudo code, solely for illustration purposes

d.Close();

[ptorr-msft]

Good news: there is already an implementation of a common deferral with ICloseable support: Windows.Foundation.Deferral, and all new deferrals should be using it.

Bad news: Older APIs don't use it, and since programs depend on using the concrete type (like, say, DragOperationDeferral) we can't replace them after-the-fact.

Good news again: We could potentially update Reunion with the common deferral class, since full binary compatibility with Windows code isn't required.

I will ensure this gets visibility internally to see if we can update code as it moves to Reunion. Thanks for pointing this out!

[ptorr-msft]

And for the "do we need to do this?" -- yes, we do :). The code that is raising the event probably doesn't want to be asynchronous / reentrant, hence it can't itself do an await on the event.

[SetTrend]

Thanks so much @ptorr-msft, for taking the time and clarifying this issue!

I'd like to add one remark on the Bad News item you mentioned:

It looks like (some of) the current, divergent, implementations don't implement IDisposable or extend any base class:

So, extending these existing classes (or have them implement IDisposable) wouldn't have an impact on existing implementations, AFAIK.

Wouldn't it make sense to have them derive from Windows.Foundation.Deferral then?

[ptorr-msft]

You can't derive from another type in WinRT (XAML does something special to make it look like derivation). But yes, in theory those types could be updated to implement ICloseable even on Windows. One of the problems though is people building version-adaptive code would be unable to use using since it wouldn't exist down-level... so probably not really a good thing to do. Reunion is different though, so keep your fingers crossed :-)