Can constructors be async?

Question

I have a project where I'm trying to populate some data in a constructor:

public class ViewModel {     public ObservableCollection<TData> Data { get; set; }      async public ViewModel()     {         Data = await GetDataTask();     }      public Task<ObservableCollection<TData>> GetDataTask()     {         Task<ObservableCollection<TData>> task;          //Create a task which represents getting the data         return task;     } } 

Unfortunately, I'm getting an error:

The modifier async is not valid for this item

Of course, if I wrap in a standard method and call that from the constructor:

public async void Foo() {     Data = await GetDataTask(); } 

it works fine. Likewise, if I use the old inside-out way

GetData().ContinueWith(t => Data = t.Result); 

That works too. I was just wondering why we can't call await from within a constructor directly. There are probably lots of (even obvious) edge cases and reasons against it, I just can't think of any. I've also search around for an explanation, but can't seem to find any.

Answer 1

Since it is not possible to make an async constructor, I use a static async method that returns a class instance created by a private constructor. This is not elegant but it works ok.

public class ViewModel        {            public ObservableCollection<TData> Data { get; set; }             //static async method that behave like a constructor            async public static Task<ViewModel> BuildViewModelAsync()       {                ObservableCollection<TData> tmpData = await GetDataTask();           return new ViewModel(tmpData);     }             // private constructor called by the async method     private ViewModel(ObservableCollection<TData> Data)     {         this.Data = Data;        } }   

Answer 2

Constructor acts very similarly to a method returning the constructed type. And async method can't return just any type, it has to be either “fire and forget” void, or Task.

If the constructor of type T actually returned Task<T>, that would be very confusing, I think.

If the async constructor behaved the same way as an async void method, that kind of breaks what constructor is meant to be. After 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.

All this is just a guess. But it seems to me that having the possibility of an async constructor brings more trouble than it's worth.

If you actually want the “fire and forget” semantics of async void methods (which should be avoided, if possible), you can easily encapsulate all the code in an async void method and call that from your constructor, as you mentioned in the question.