Pseudo Constructors

[MarcelloPoletti]

Hi,

The issue of asynchronous constructors has already been discussed, albeit without a solution, in various topics (#419, dotnet/roslyn#6788).
Here, an alternative and more general approach is proposed to achieve a satisfactory result.

Consider an object that requires asynchronous initialization; asynchronous constructors, as extensively discussed, are extremely problematic. Therefore, the solution currently available involves separating the operations:

public class Foo
{
  public Foo(){}
  public Task InitAsync(){...}
}
var o = new Foo();
await o.InitAsync();

This syntax is cumbersome as it requires the caller to construct an object in two steps and can be improved with a static method:

public class Foo
{
  private Foo(){}
  public static async Task<Foo> CreateAsync()
  {
     var o = new Foo();
     await something;
     return o;
  }
}

This is a standard syntax that we could call the "Factory Pattern." It works, but:

• It is verbose and unnatural
• It does not allow access to initializers: await Foo.CreateAsync(){Property1=1}
• It does not allow access to this
• It does not allow access to read-only properties
• It entails an unnatural handling of nullability

One possible way out is as follows:
Let's define any static method inheriting from a constructor as a pseudo-constructor. Here are two examples, one related to asynchronous constructors and the other in a completely different context:

public class Foo
{
  private Foo(){}
  public static async Task<Foo> CreateAsync():this()
  {
  }
  public static int Calculate():this()
  {
  }
}

1. A pseudo-constructor implicitly creates an instance that can be accessed via this, even if omitted.

public class Foo
{
  string SomeText;
  private Foo(){}
  public static async Task<Foo> CreateAsync():this()
  {
      this.SomeText="abc";
      await something;
      return this;
  }
  public static int Calculate():this()
  {
      SomeText="123";
      return 1;
  }
}

2. A pseudo-constructor accesses read-only properties using the same rules as a constructor.

public class Foo
{
  string SomeText{get;}
  private Foo(){}
  public static async Task<Foo> CreateAsync():this()
  {
      this.SomeText="abc";
      await something;
      return this;
  }
  public static int Calculate():this()
  {
      SomeText="123";
      return 1;
  }
}

3. A pseudo-constructor follows the nullability rules of a constructor. See C#8 with nullable compiler only checks code in constructors before producing CS8618 warning roslyn#32358.

4. A pseudo-constructor that returns this or an awaitable of this allows initializers:

var f = await Foo.CreateAsync(){Property1=1}
var i = Foo.Calculate(){Property1=1}

marc.

[colejohnson66]

I'd honestly just prefer async constructors over factory-like hacks.

[MarcelloPoletti]

@colejohnson66,

For a long time, I thought about it too, then I changed my mind. Even if asynchronous constructors were technically implementable, they would still be a messy solution. First of all, the typical "Async" suffix is missing, which explicitly indicates the nature of the operation, so you would end up writing:

var x = new Foo();

Without it being clear at all that x is a Task, not a Foo! Furthermore, the inheritance of constructors is skipped, what sense would something like this make:

public async Foo() : this/base(...)?

The proposed solution avoids all these ambiguities, making the asynchronous operation completely explicit (CreateAsync, BuildAsync, GetAsync..) and, it seems to me, making the reading and writing of the code natural and smooth.

[colejohnson66]

Some comments have proposed requiring some new keyword like asyncnew Foo() to call an async constructor. Under the covers it would just call a compiler-generated factory method. Specifically, new Foo() would be a compiler error if an asynchronous constructor was defined. However, you bring up a good point about base class initialization and chained constructors.

Special syntax support for factory methods (as you and #6602 propose) are probably the best we’ll get with C#, should such a concept even be implemented.

[MarcelloPoletti]

Of course, it would be possible to simply make constructors non-inheritable asynchronously, but it is clear that something is happening. A new keyword is needed to call a constructor that does not return the declared type and does not behave like a constructor (is not inheritable)... mmm... it doesn't work! It's neither natural nor spontaneous.

So let's reverse the reasoning: okay, constructors are constructors and remain as they are, but any static method that returns type X is a kind of constructor for X (a pseudo constructor). Not really, not every static method, but a static method that creates a new instance of X. Now, there is tension between the "intention" to create type A and the returned type:

public static A BuildA();
public static void UseA();
public static Task<A> BuildAAsync();

These methods are pseudo constructors of A in the sense that they instantiate an A, regardless of what they do. Trying to understand the meaning of this, it seemed to me that everything became coherent by inheriting from a constructor:

public static A BuildA():this(...);
public static void UseA():base(...);
public static Task<A> BuildAAsync():this(...);

Note that it is not strictly necessary for the method to belong to the class; enthusiasts of factories, understood as separate classes, could inherit from a public constructor:

public static A BuildA():A(...);

The syntax:

var a = BuildA(){Properties}

Becomes, transparently equivalent to:

var a = new A(){Properties};
BuildA(a);

Where:

1. BuildA accesses the implicit variable a via this (!!!)
2. BuildA does whatever it wants, it does not necessarily have to return an A but also a Task or void (!!!)
3. BuildA allows setting readonly properties and correctly managing the nullability chain.

Point 3 is the most delicate because, I believe, it is not correct for an external method to access readonly properties, so:

• Either pseudo constructors are only allowed in the owning class (:this())
• Or access to readonly properties is only allowed in the owning class.

[HaloFour]

#6602