Discussion: async constructors

[alrz]

Moved from dotnet/roslyn#6788

async constructors

Declaration

class C : B
{
  private readonly T1 _f1;
  private readonly T2 _f2;
  
  // async ctor calling non-async this or base ctor initializer
  public async C(P1 p1, P2 p2) : base(...)
  {
    _f1 = await GetDataAsync(p1);
    _f2 = await GetDataAsync(p2);
  }
  
  // async ctor calling an async this ctor initializer
  public async C(X x) : await this(x.p1, x.p2)
  {      
    await x.MethodAsync();
  }
  
  // async ctor calling an async base ctor initializer
  public async C(Y y) : await base(y)
  {     
    await y.MethodAsync();
  }
}


// equivalent:


class C : B
{
  private readonly T1 _f1;
  private readonly T2 _f2;
  
  #region first constructor
  
  // generated private ctor to initialize readonly fields
  // and pass parameters that are referenced in the ctor initializer
  private C(T1 f1, T2 f2, ...) : base(...)
  {
    _f1 = f1;
    _f2 = f2;
  }
  
  // generated to be used in derived types in case of non-sealed classes
  protected static async Task<(T1, T2)> ConstructorAsync(P1 p1, P2 p2)
  {
    // constructor body
    var f1 = await GetDataAsync(p1);
    var f2 = await GetDataAsync(p2);
    return (f1, f2);
  }
  
  // factory method with async ctor parameters to create the final object
  public static async Task<C> CreateAsync(P1 p1, P2 p2)
  {
    // constructor body can go directly here in case of a sealed class
    var (f1, f2) = await ConstructorAsync(p1, p2);
    
    // p1 and p2 could be passed here if they are used in the ctor initializer 
    return new C(f1, f2, ...);
  }
  
  #endregion
  
  #region second constructor
  
  protected static async Task ConstructorAsync(X x)
  {
    await x.MethodAsync();
  }
  
  public static async Task<C> CreateAsync(X x)
  {
    var c = await CreateAsync(x.p1, x.p2);
    await C.ConstructorAsync(x);
    return c;
  }
  
  #endregion
  
  #region third constructor
  
  protected static async Task ConstructorAsync(Y y)
  {
    await y.MethodAsync();
  }
  
  public static async Task<C> CreateAsync(Y y)
  {
    // possible awaited results from base classes
    var (...) = await B.ConstructorAsync(y);
    await C.ConstructorAsync(y);
    return new C(...);
  }
  
  #endregion
}

Usage

// constructor returns a Task
Task<C> v1 = new C(p1, p2);
// equivalent:
Task<C> v1 = C.CreateAsync(p1, p2);


// await the constructor
C v2 = new await C(p1, p2);
// equivalent:
C v2 = await C.CreateAsync(p1, p2);


// await the (extension) awaitable, if any (existing syntax)
var v3 = await new C(p1, p2);


// await methods on the returned Task
C v4 = await new C(p1, p2).ConfigureAwait(false);
// equivalent:
C v4 = await C.CreateAsync(p1, p2).ConfigureAwait(false);


// await methods on the awaited constructor
var v5 = await new await C(p1, p2).MethodAsync();
// equivalent:
var v5 = await (await C.CreateAsync(p1, p2)).MethodAsync();

Notes

• This proposal does not incur any clr changes. However, with clr support, it would be a lot simpler to achieve the same effect.
• The suggested transformation is not comprehensive. We should define a set of rules for the precise form of the final type in various cases (which depends on clr changes being an option).

[john-cd]

Hmmm... You can technically do that with a void-returning async method already.

I would not advise doing that or implementing the above, however; that sounds like an antipattern.

"After the constructor returns, you should get a fully initialized object. Not an object that will be actually properly initialized at some undefined point in the future. That is, if you're lucky and the async initialization doesn't fail."

Do we really want to deal with half-baked objects, which initialization can take an arbitrarily long time, occur at an unpredictable time, or fails in unpredictable ways, throwing all sorts of exception, including I/O?

Until the object is constructed, there would be no real way to monitor the state or cancel or provide progress reports.

You noticed that an async constructor could be called on one thread, then finish on another. Sounds like a debugging nightmare.

In addition, most developers assume that constructors do not throw, except developer-misuse exceptions (ArgumentException).

This feature would introduce the same difficulties in object initialization than we currently have with object destruction (unpredictable GC, etc...).

This said, there clearly is a need for async initialization. I would suggest to rethink the object lifecycle as whole and create a standard "init" pattern - implemented perhaps via a new standard interface, an init analog to IDisposable - instead of trying to cram everything in the constructor:

1. Construction: hydrate the object and its fields in memory. It should be synchronous and as atomic as possible. At the end of this phase, all fields... are created and initialized to a default (but not always usable) value; the object state is defined and coherent (but not necessarily useful just yet); and events and properties are available.

2. The caller wires events.

3. Initialization: bring the object from its "born" state to its "adult" useful state. That phase could be synchronous or asynchronous. Cancellation, monitoring and progress reporting should be possible during that phase.

[benaadams]

Isn't it unexpected that new ObjectType() isn't returning the actual object type; but an awaitable type?

Should it also work with tasklikes e.g. ValueType<ObjectType> if for example its async as its a constrained/queued resource rather than always async (e.g. why is it double allocating)

[HaloFour]

My objections, TL;DR:

1. The result isn't a constructor but a static factory with some voodoo.
2. Constructors probably shouldn't be doing the kind of heavy lifting implied by an asynchronous operation.
3. The proposed consumption syntax is already legal C#, a different syntax is required to avoid ambiguity.
4. These constructors would not be able to assign values to any readonly fields, at least not if those fields are properly initonly to the CLR, since the initialization logic taking place after any asynchronous operation could not execute within the actual constructor body of the class.

[alrz]

@HaloFour

The result isn't a constructor but a static factory with some voodoo.

It being a constructor syntactically would allow us to manage inheritance and constructor chaining which is not that straightforward if written manually, it requires rather complicated logic depending on various aspects.

Constructors probably shouldn't be doing the kind of heavy lifting implied by an asynchronous operation.

The generated private constructor does not do the heavy lifting. It's just the input syntax that is useful in the cases mentioned above.

The proposed consumption syntax is already legal C#, a different syntax is required to avoid ambiguity.

No, I'm using new await to await the constructor itself. See the "Usage" part.

These constructors would not be able to assign values to any readonly fields,

With the transformation I've suggested we first calculate awaited values and pass them to a real constructor to be assigned to readonly fields, so no clr change is required, albeit preferable for an efficient implementation.

[alrz]

@benaadams

Isn't it unexpected that new ObjectType() isn't returning the actual object type; but an awaitable type?

This was mentioned in the original issue as I was proposing a different syntax to instantiate such types. I've removed it based on @CyrusNajmabadi suggestion. You could use the "Async" suffix naming convention just like methods for that to indicate that it has an async constructor and can be awaited, for example.

[HaloFour]

@alrz

With the transformation I've suggested we first calculate awaited values and pass them to a real constructor to be assigned to readonly fields, so no clr change is required, albeit preferable for an efficient implementation.

Which would render it impossible to reference this in any way, including to invoke other members on the instance or to pass that instance to some other method. If anything that's an even worse restriction.

[alrz]

@HaloFour

It's possible to call this in the constructor, but you can't await an expression that referenced it.

[HaloFour]

@alrz

It's possible to call this in the constructor, but you can't await an expression that referenced it.

When? Not if this doesn't exist yet. If you defer the actual instantiation of the method until as late as possible in order to support initonly fields then when this may be referenced becomes seriously constrained. At best it would be after any readonly field has finally been assigned and the actual constructor is invoked. The compiler could probably get trickier, but probably not beyond how it can be described reasonably in the spec.

Factory methods aren't pretending to be constructors. They don't come with any expectation that you can refactor an existing constructor by sprinkling a few awaits around and "it just works".

[jnm2]

I'd prefer new TypeWithAwaitableCtor() to return a Task<TypeWithAwaitableCtor>, so that await new TypeWithAwaitableCtor() just works and so does new TypeWithAwaitableCtor().ContinueWith.

Notice that this does not break backward compatibility. The only break in back-compat would come when you change the definition of TypeWithAwaitableCtor by adding the async keyword to the constructor; that may or may not be a breaking API change, depending on whether the type is one of the handful of types that is itself awaitable. It's going to be rare to the point of hilarity for a type which is itself awaitable to have any need for an async constructor- that smells of mixing primitives with higher-level constructs. And if we were worried about extension methods preventing us from adding methods to classes without changing the meaning of code, all types would be unchangeable once shipped.

[alrz]

@HaloFour

We extract out all await expressions to the factory method and the constructor only gets the result.

sealed class C
{
  private readonly T1 _f1;

  public async C() => _f1 = this.F(await GetData()); 

  // ->

  private C(T1 f1) => _f1 = this.F(f1);
  public static async Task<C> CreateAsync() => new C(await GetData());
}

The await expression may not rely on this directly or indirectly. I can see how this can get complicated but I think a fair amount of restrictions to support readonly fields is reasonable. Passing this in the constructor (specially for immutable types) is not considered a good practice after all.

[alrz]

Constructors probably shouldn't be doing the kind of heavy lifting implied by an asynchronous operation.

About this, in Rust for example, a constructor is just a convenient method to create the object. Every type gets a "default constructor" that requires every field to be initialized, it does not allow you to run any actual logic in it, so you may not call any instance method before the final object is fully initialized. It's restricted on the language level while in C# it's still possible probably for historical reasons. So referencing this in the constructor should be your least concern here cause that itself is against your will to use the constructor merely for initialization and avoid partially-constructed objects.

[HaloFour]

@alrz

We extract out all await expressions to the factory method and the constructor only gets the result.

Indeed, which is exactly why you can't touch this until after that final await. But even then it's not legal because you allow chaining asynchronous constructors so you don't know when that final await is.

Passing this in the constructor (specially for immutable types) is not considered a good practice after all.

It's bad practice to call instance methods? Set instance fields or properties? Not in C# it's not. You can't even chain to synchronous base constructors in the order described by the source. The amount of code-rewriting/reordering that would be required to facilitate supporting initonly fields would be ridiculous.

[alrz]

@HaloFour

It's bad practice to call instance methods? Set instance fields or properties? Not in C# it's not.

That's why I said "passing", in case of a field or auto property you are not passing this, calling a method, however, is risky because this is a partially-constructed object by then and could be a source of bugs.

All in all, I admit that if we use constructors merely for initialization and factor out async constructor initializers, async constructors do not provide much value compared to factory methods. The question is that how much those patterns are common and what are the alternatives.

[aluanhaddad]

I feel like a static factory is sufficient to handle these scenarios. I also think they are easier to read.
That is the following is (to me)

var x = await SomeType.CreateAsync(a, b);

easier to understand than

var x = await new SomeType(a, b);

Additionally, factories have several advantages

• factories are subject to delegate conversions
• factories may return alternate implementations
• it is possible to abstract over factories
• factories can be given descriptive names

Another, reason I don't think this is a great idea is that the return type of a constructor is not something that one generally considers. Constructors just create instances of their class. But with async constructors, you end up thinking about the return type which adds complexity and increases cognitive load. This is doubly true given the possibility of custom awaitables and ValueTask<T>.

[MgSam]

TLDR; In favor of this because:

• Static factories are a lot of boilerplate code to write.
• Many (most?) programmers don't know enough to write them at all- so instead they do horrible things like call .Result on Task in the constructor instead.
• Doing some asynchronous task before an object is ready to be used is an extremely common pattern, (whether you like or not :)
• Everywhere else in the language and framework has made it easier for you to use async. Constructors punish you for using async.
• Pragmatism before idealism

[operationslazlo326]

As it appears there is no technical reason why constructors couldn't be asynchronous, the discussion seems to boil down to two issues.

1. Should the investment in implementing async constructors be made

I think the answer to this is yes, as the following are true

Developers are calling Wait() in constructors (obviously bad)
Developers are resorting to incompatible patterns for making sure their classes are ready for use post constructor. That's obviously less than ideal as they aren't truly standard, which prevents tooling / frameworks from supporting them.

2. Proposed syntaxes

Is there anything wrong with...

public async ClassName
{

}

This isn't legal syntax now, so it wouldn't break anything and it's very concise. I know nothing about compiler implementation, but it seems like the compiler should be smart enough to emit the above code as an awaitable Task.

It already looks like C# 9 is tackling issues related to class initialization, it would be a shame if async constructors didn't make the cut.

[333fred]

It already looks like C# 9 is tackling issues related to class initialization, it would be a shame if async constructors didn't make the cut.

Regardless of anything else, we're not going to get to async construction in C# 9. With the exception of a couple of very small features, everything that is going to make it has been shipped with 16.7 preview 3.

[IanKemp]

Bump - any update on this? C# 10.0 maybe?

[YairHalberstadt]

In general, if there's no new comments on a discussion/issue, nothings happened. In this case I don't know of any recent discussion about this feature by the language team, so it's almost definitely not going to happen in C# 10 (which is 8 months away, and already has a very full pipeline).

[DirkBoer]

In favor!
I agree with pragmatism above idealism. async/await has been one of the larger important patterns that significantly changed codebases throughout. Everyone is writing their own CreateAsync methods anyway. In reverse you could also argue why we need to have public constructors if we could create everything with a Create() Factory method and private constructor. The reason is: readability.

It will make codebases easier to read when we standardize such an important pattern.

[DirkBoer]

Also it adds discoverability. As much as possible being able to use new X() is actually a lot more discoverable then to figure out when or what factory method you have to use.

[jeremysimmons]

I am in favor of this because of of modifying the SqlConnection inside the constructor of the EF DbContext

using System;
using Microsoft.Azure.Services.AppAuthentication;
using Microsoft.Data.SqlClient;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Logging;
using Nito.AsyncEx.Synchronous;

public partial class FooDbContext : DbContext
  {
    public FooDbContext(DbContextOptions<FooDbContext> options, ILogger<FooDbContext> logger)
        : base(options)
    {
      try
      { 
        // This is to check to see if the connection is going to azure, if it is we get the
        // access token. If we already have an access token we just use the existing token.
        // ReSharper disable once VirtualMemberCallInConstructor
        var conn = (SqlConnection)Database?.GetDbConnection();
        if (conn?.DataSource?.Contains("database.windows.net") == true)
        {
          var tokenProvider = new AzureServiceTokenProvider();
          var task = tokenProvider.GetAccessTokenAsync("https://database.windows.net/");
          task.WaitAndUnwrapException();
          conn.AccessToken = task.Result;
        }
      }
      catch (Exception ex)
      {
        logger.LogCritical(ex, $"Unable to initialize {nameof(DebitCardsDbContext)}.");
        throw;
      }
    }

[AartBluestoke]

Does anyone know which is the current 'best practice' way of solving / implementing a workaround for this?

1. "it is not appropriate to use any network or disk resources to initialize your object. If you require such things you are supposed to read those objects asynchronsly as needed prior to construction then pass them it. All users of the object are required to have access to these external resources."
2. "It is appropriate to use .GetAwaiter().GetResult() in constructors"
3. "It is fine to write a constructor which leaves an object in an unconstructed state, expecting some other async function later to complete initialization, and trusting that it will be called."
4. "In such situations which require access to network resources, constructors are not supposed to be public, but a user chosen factory or builder pattern is to be used instead."
5. "It is not appropriate to use objects requiring complex initialization in combination with any libraries which require use of async".

I know i've resorted to some of these myself in the past... (i think i've done 1,2,4,5)

[jeremysimmons]

best practice is the one that's documented, with code examples, easily accessible to the team, and followed by all in code reviews

this is a topic that's subjective.

[PeterWone]

Your team should understand really clearly that creating an object and getting it ready to use are two separate things. There are various ways to skin this cat, from async static factory methods to async init methods. My favourite is exposing a Ready promise (Task in C#) as a property of the class in question. Do it that way and anywhere the object is available you can make your code wait on its readiness.

Does anyone know which is the current 'best practice' way of solving / implementing a workaround for this?

1. "it is not appropriate to use any network or disk resources to initialize your object because they can block for a really long time. If you require such things you are supposed to read those objects asynchronsly as needed prior to construction then pass them it. All users of the object are required to have access to these external resources." Or you can use one of the approaches I mentioned in my preamble.
2. "It is appropriate to use .GetAwaiter().GetResult() in constructors" because an awaiter won't block a thread.
3. "It is fine to write a constructor which leaves an object in an unconstructed state, expecting some other async function later to complete initialization, and trusting that it will be called." See preamble.
4. "In such situations which require access to network resources, constructors are not supposed to be public, but a user chosen factory or builder pattern is to be used instead per preamble ."
5. "It is not appropriate to use objects requiring complex initialization in combination with any libraries which require use of async" to the extent that now you have two hard problems and the difficulty multiplies. They just mean don't make it harder than it actually is. Sometimes it really is that hard.

I know i've resorted to some of these myself in the past... (i think i've done 1,2,4,5)

Jeremy Simmons already told you to be consistent across your codebase so I won't labour that.

[Richiban]

[1] or sometimes [4], all the way.

I'm in agreement with some of the voices here; anything async shouldn't be done in an object's constructor.

[MGRussell]

I'd also like to see this because of one other issue that the factory pattern runs into. Since the object is not being initialized in the constructor, readonly properties don't work. The C# 9 init keyword paired with a private default constructor works as a work-around, but when the interface to the object is leaking so many details of implementation work-arounds, it's time to call in a plumber.

[frankhaugen]

Interesting to see how this thread has gotten a lot of traction but when I suggested it a couple of years ago, it got one simple, "no, the point of a constructor is to run before logic, closed" -answer.

Anyway, I really like the suggestion about adding the async keyword on the class to communicate that this has asynchronous constructors, but what if I want a synchronous constructor as well? Will i be forced to always do a var someClass = await new SomeClass();? (And yes I would expect there to be an await when making a new instance)

I bring this up because I would want to apply this when I inherit from an abstract class, but that class might not be an "async class"

[Thaina]

This seem to be able to handled normally with overloading and target typed feature like any other function

[TahirAhmadov]

I understand both the arguments that async ctors are useful, and that static factory methods get the job done. I just want to add that BCL is partially at fault here, and this goes back to the very beginning. Classes like FileStream have a sync ctor which performs an operation which is fundamentally should be async. (There is a whole different topic with OS support for async CreateFile, etc.) This dilemma of async ctor vs async factory method should probably include the decision of what to do with those classes. Mind you, in other places, like Socket, ConnectAsync is a separate method.
What I mean is that if we have a unified approach of "ctors are always simple initializers and don't do any real work", and that approach is propagated in BCL and the wider ecosystem by means of offering a standard guidance (think language best practice type of document), it probably makes sense to stick to factory methods.
Having said that, this was a good suggestion to ask and discuss.

Another point: @aluanhaddad mentioned that factory methods (in addition to already being available) are better because they can be referenced by delegates. Is it possible to (either using a language trick or in the runtime) to create constructor delegates? (This is outside of the async ctor topic.) Does it add enough value over a lambda () => new Foo()?

[PeterWone]

I read your response and thought about how to wrap it all up in syntactic sugar. The conclusion I reached is that this would produce complex implicit behaviour and steep learning curves. However, you way requires that the change in behaviour should be _requested_. I could go with that. Also, there is the fact that readiness is a property of the object unrelated to construction. A database connection object may be ready, have a network glitch, go unready, then recover and be ready again. You can solve that with exactly the same readiness pattern, and your notation could be applied.

I wonder why these guys are having such difficulties... dotnet/aspnetcore#24142<dotnet/aspnetcore#24142>

If they used the readiness pattern and people let go of the sometimes unsatisfiable expectation that everything will be ready quickly, the problem would stop being hard. It wouldn't satisfy your aesthetic, but that's another matter. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

…

________________________________ From: Jack Bond ***@***.***> Sent: Saturday, February 12, 2022 10:02:20 PM To: dotnet/csharplang ***@***.***> Cc: Peter Wone ***@***.***>; Mention ***@***.***> Subject: Re: [dotnet/csharplang] Discussion: async constructors (Discussion #419) "Your team should understand really clearly that creating an object and getting it ready to use are two separate things." Even though I completely disagree with that statement, I'm going to go ahead and accept it for sake of argument. If being ready is a real world distinction, than THE ENTIRE ECOSYSTEM should recognize and promote it to an officially recognized and supported construct. And let's roll with your Ready property. For example, when I've been passed an object, I don't want to have to check if its ready every time I use it, so let's add a c# operator, how about !!! which tells the compiler "Check if this thing is ready, and if it isn't, then make it ready" For example, public class Foo { public Foo(Bar !!!bar) { } } is obviously cleaner than public class Foo { public Foo(Bar bar) { bar.Ready().Wait(); } } We now live in an injection world, when I'm handed an object, I expect it to be ready without having to check something. I wonder why these guys are having such difficulties... dotnet/aspnetcore#24142<dotnet/aspnetcore#24142> — Reply to this email directly, view it on GitHub<#419 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABJ6QODBCRAOVYFS6QQLKTTU2ZD4ZANCNFSM4V4RDOIQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[DirkBoer]

So the whole direction of the language is to get rid of all the noise and boilerplate.

Can someone tell me what the most readable way is to just have a constructed enclosed object that needs some Async initialization in there?

I'm getting so tired of everytime writing the same:

public class SomeClass

	private SomeClass()
	{
	}


	private async Task InitAsync(int param1, int param2)
	{
		// do db stuff and other IO stuff
	}


	public static async Task<SomeClass> CreateAsync(int param1, int param2)
	{
		var obj = new SomeClass();

		await obj.InitAsync(param1, param2);

		return obj;
	}
  }

while this could have just been:

public class SomeClass
{
	public async SomeClass(int param1, int param2)
	{
		// do db stuff
	}
}	

Yes, you can in theory get rid of the InitAsync - but now you have to refer to the obj constantly to init all the proprties, because you are in a static method.

This means suddenly the code doesn't look at a constructor anymore, while practically it is a contructor. Also this looks really ugly and you have to repeat it everywhere in your code:

public class SomeClass

	private SomeClass()
	{
	}

	public static async Task<SomeClass> CreateAsync(int param1, int param2)
	{
		var obj = new SomeClass();

		obj.property1 = await // db stuff
		
		if ( obj.property2 != null )
			obj.property3 = await // db stuff

		return obj;
	}
  }

Code is all about readability. Ask 100 people that are new to the language (free of dogma, like you and me) which of the above is most readable and understandable and I'm pretty sure 95% will answer the async constructor version. I'm open to do a survey about that.

I'm also pretty sure they can explain how it works and what to expect.

I understand this feature request faces a lot of backlash.

Some people are used to work with a lot of abstractions, layers mocks and whatever not, I don't think that a universal language like C# should dictate this onto others. In your own projects you can just tell other people they can't use async constructor like some people forbid to use var.

[TahirAhmadov]

And what if the hostname comes from an async configuration provider?

What's an "async configuration provider"?
I can imagine a situation in which certain settings are stored somewhere remotely and getting them would be async, like a DB, but why not get that setting as part of the async operation?

record WeatherInfo(int Temperature, int WindStrength);
static class WeatherInfoWebGetter
{
  public static async Task<WeatherInfo> GetWeatherAsync(int param1, int param2)
  {
    var request = new JsonRequest(await GetApiUrlAsync());
    var json = await request.GetAsync();
    return new(json.temp, json.wind_strength);
  }
  static async Task<string> GetApiUrlAsync() { ... }
}
// or even, if you want standardized async config retrieval:
record Config(string WeatherApiUrl, string OtherSetting); // etc.
static class ConfigGetter
{
  public static async Task<Config> GetConfigAsync() { ... }
}

Still, I find it very unusual that an API URL needs to be stored somewhere away from the application. Doesn't look like something which changes in real time - which is usually the requirement which is accommodated with DB-stored or remotely provided settings.

in the real world, developers do ugly hacks every day

I understand that very well, but I don't think the language design should take its clues from "ugly hacks".

Let's take the FileInfo class

That was created way before async. What's more, even today not all file operations are available in async mode in Windows.
Totally agree though, it should be GetExistsAsync() method, not Exists property.

[HaloFour]

In the case of DI the di system would need to be updated to support this just like with any task-based factory pattern.

Notably the work required to support asynchronous constructors would be exactly the same work required to support asynchronous factory methods. Adding asynchrony to an existing DI container is an extremely non-trivial task.

See: dotnet/runtime#65656

[333fred]

Constructors not being async was a resource constraint, it wasn't rejected, otherwise this thread wouldn't still be open.

I just want to clarify something: we generally do not close discussions on GitHub. Just because a discussion is open, and has been open for a while, does not mean that the LDM has generally looked at it or made any kind of judgement on it. Issues, specifically championed issues, are how we keep track of items that have been brought to the LDM. At this point, no LDM member, Cyrus and myself included, have expressed an interest in championing the issue. There are many serious concerns about how this feature would work; not just from an ideological point of view, but also from a "How in the world would this be implemented?" point of view. Methods as they exist today have many customization points for asynchronicity: what type of task does it return? How does the compiler customize the generated state machine builders? Reinventing all of that syntax for constructors does not seem like a worthwhile investment to me.

[TahirAhmadov]

Then other questions come up. Do we allow a new constraint for generics async new? Or is it await new? What to do with calling base ctors, do we mandate that it has to be await base()? There is a large number of syntax changes. And I'm definitely not even listing all the possible questions.

[DirkBoer]

I think base constructors is handled in the proposal above here. I don't right now have the mental space to think this through because I'm in the middle of my working day and if it you CAN omit this specific case, but of course you don't need to incorporate every single case in the first implementation. We also can't have parameters in a new() constraint. Still covers the 99% case.

I don't mind any timeline, I'm here for the long duration, but:

• async is eating the world
• the overall C# trend seem to be simplify the language and get rid of boilerplate code

But:

• if you want an async constructed object you will always need to create two methods.
• as a user of the class there is no consistent way to create it. Should I look at a static method on the class? Do I need to find somewhere a related factoryclass? Is it CreateAsync NewAsync, etc.

On the long term these two visions don't seem to match to me.

I really would like to see people learning the language and then coming across this problem.

I'm pretty sure shivers run along their spine with the question "why am I caring about all this stuff? Why is the compiler not doing this for me?"

The similar feeling we all had when we were still working in Java 😄

[StephenCleary]

I'm not convinced a language feature is the best solution. There's a fair amount of discussion happening re async startup and service resolution in ASP.NET (see dotnet/aspnetcore#24142 and friends). A library solution may handle the 90% case without making a language change that has far-reaching effects.

[chrisoverzero]

Yet it increasingly feels like "the team isn't interested, write a source generator to do it yourself" is becoming the default response to any user-suggested feature. That's not a good look.

It is tremendously harder to get a language feature into C# than it is to write a source generator. Of course it's going to be the suggestion for most requests. It's far better to have a solution where a developer writes partial and an attribute to solve their problem today than it is to write a new keyword three language versions from now.

[CyrusNajmabadi]

Also, generators a have the benefit of being very flexible, configurable, and under far less constraints than a language feature (which needs to stay virtually fixed for decades).

[DirkBoer]

@HaloFour @CyrusNajmabadi "The team is not interested" you can always use to quell any discussion.

The whole reason why this is open source and people can have discussions about this is to make a case for their needs and their views on the future of the language.

The question is why are you guys so invested in this feature to not be there?

If I look at the amount of positive reactions on the start of this thread I would say this is somewhere in the top 20 of features.

[CyrusNajmabadi]

The question is why are you guys so invested in this feature to not be there?

WDYM? I'm not invested this feature not being added.

The whole reason why this is open source and people can have discussions about this is to make a case for their needs and their views on the future of the language.

Yes. And as part of a discussion, people can put forth their views as well. :)

If I look at the amount of positive reactions on the start of this thread I would say this is somewhere in the top 20 of features.

It's also one of the more contentious and heavily skewed features, with a lot of negative feelings about it.

[jnm2]

Or, to be clear, the thing source generators let you do is have something within five years, even when the team is interested. It's not enough for it to be a good idea, it has to beat all the other good ideas.

[colejohnson66]

So, there are two fields of thought here about what a constructor is in terms of creating/filling in (i.e., constructing) an object

• One that does the most minimal work necessary
• One that does any and all work necessary (even I/O)

@TahirAhmadov has been advocating for the former and @DirkBoer for the latter. There's an ideological disconnect, and it butts heads when I/O (or anything asynchronous) is thrown into the mix. After all, why is synchronous I/O acceptable, but not asynchronous I/O? Maybe synchronous I/O isn't acceptable to you, but it's what exists, for better or worse. Hence, this request (and others) for asynchronous constructors.

Regardless, as it stands now, the LDM has decided not to entertain this idea, and continuing to argue past each other about it doesn't do anything.

[colejohnson66]

The problem with factory methods like this is that they clash with readonly fields and init properties; Those can only be set in the constructor. With a dedicated "init" method, you lose that flexibility, as you're forced to remove the readonly modifier and replace init with set (which could be dangerous). Now, your source generator needs to bundle a complex analyzer that creates errors if they're accessed in the wrong spot.

[HaloFour]

Sure, but personally I don't see that being much of a problem. You can already control the mutability of that state through the property accessors you expose, so publicly the type can remain as immutable as you desire. Personally, if one had that much concern about eliminating the ability to observe the instance in a partially-initialized or mutable state, you'd use proper factory methods anyway.

The perfect is the enemy of the good, and it seems that the alternative is waiting another 9 years for no movement in this space.

[CyrusNajmabadi]

The problem with factory methods like this is that they clash with readonly fields and init properties; Those can only be set in the constructor. With a dedicated "init" method, you lose that flexibility, as you're forced to remove the readonly modifier and replace init with set (which could be dangerous). Now, your source generator needs to bundle a complex analyzer that creates errors if they're accessed in the wrong spot.

Note: we are very interested in embracing enhancements to factory methods, especially around init/required.

[HaloFour]

Note that in the case above the await operator has lower precedence so object initializer syntax would work fine. Reworking the generation a little bit you could trigger the InitAsync method on first GetAwaiter which would allow it to take into consideration the values of those properties.

SharpLab

var c = await new C(1, 2) {
    X = 123,
    Y = 456
};

[TahirAhmadov]

@colejohnson66

While I'd agree with you, that belief doesn't match that of the runtime. Tons of things in System.IO perform work in their constructors.

And like I wrote previously, 99% of those things were created way before async. Changing all that requires essentially a do-over.
I'm collecting signatures for a petition to re-write .NET and C# from scratch. Your support would be appreciated. 😉

Even non-I/O work that, according to you should be outside a constructor, happens; Many times I've seen timers constructed, events subscribed, etc. all in the constructor. Where do you draw the line between what is acceptable and what isn't?

I never said non-IO work shouldn't be in ctor; timer construction, events subscription, etc. are perfectly valid in ctors in my book. These operations are instantaneous, with non-existent chance of failure, and are synchronous - I don't see any problems here.