{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/roslyn/issues/6788","repository_url":"https://api.github.com/repos/dotnet/roslyn","labels_url":"https://api.github.com/repos/dotnet/roslyn/issues/6788/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/roslyn/issues/6788/comments","events_url":"https://api.github.com/repos/dotnet/roslyn/issues/6788/events","html_url":"https://github.com/dotnet/roslyn/issues/6788","id":116996721,"number":6788,"title":"Proposal: Asynchronous Construction","user":{"login":"alrz","id":3105979,"avatar_url":"https://avatars.githubusercontent.com/u/3105979?v=3","gravatar_id":"","url":"https://api.github.com/users/alrz","html_url":"https://github.com/alrz","followers_url":"https://api.github.com/users/alrz/followers","following_url":"https://api.github.com/users/alrz/following{/other_user}","gists_url":"https://api.github.com/users/alrz/gists{/gist_id}","starred_url":"https://api.github.com/users/alrz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alrz/subscriptions","organizations_url":"https://api.github.com/users/alrz/orgs","repos_url":"https://api.github.com/users/alrz/repos","events_url":"https://api.github.com/users/alrz/events{/privacy}","received_events_url":"https://api.github.com/users/alrz/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/dotnet/roslyn/labels/Area-Language%20Design","name":"Area-Language Design","color":"5319e7"},{"url":"https://api.github.com/repos/dotnet/roslyn/labels/Discussion","name":"Discussion","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":118,"created_at":"2015-11-15T15:12:36Z","updated_at":"2016-10-18T18:58:18Z","closed_at":null,"body":"Inspired by an [article](http://blog.stephencleary.com/2013/01/async-oop-2-constructors.html) on async initialization:\r\n\r\n> It would be useful to be able to use `await` in a constructor, but this would mean that the constructor would have to return a `Task<T>` representing a value that will be constructed in the future, instead of a constructed value.\r\n\r\nThe point is, to be able to write:\r\n```cs\r\nclass Foo {\r\n    public async Foo() {\r\n        // await\r\n    }\r\n}\r\n```\r\nTo not alter the existing  constructor semantics, the compiler would generate an `async` method corresponding to the `async` constructor and use it to initialize the object.\r\n\r\nFor local variable declaration we use\r\n```cs\r\nvar foo = await new Foo();\r\n```\r\nThis should be integrated with \"async disposables\"  #114 and  #5881 so that when it's out of scope, the disposal should be taken care of.\r\n```cs\r\nusing foo = await new Foo();\r\n```\r\nIt's a compiler error if one called an `async` constructor without `await`. in order to get the involving `Task` you may use the following syntax:\r\n```cs\r\nFoo foo = new Foo(); // compiler error\r\nTask<Foo> foo = new async Foo(); // OK\r\nFoo foo = await new Foo(); // OK\r\n```\r\nFor initializing class fields we do as usual:\r\n```cs\r\nasync class Bar {\r\n    private Foo foo = await new Foo();\r\n}\r\n```\r\nThis makes the whole class `async` because you cannot instantiate this class with any of regular (or, obviously, `async`) constructors without `await new` or `new async` anymore.\r\n\r\nAlso, for async disposable types, the #111 should be taken into account.\r\n```cs\r\nasync class Bar {\r\n    private using Foo foo = await new Foo();\r\n}\r\n```\r\n`async class` can be used also for classes that use `await` on methods in field initialization:\r\n```cs\r\nasync class Baz {\r\n    private Foo foo = await GetFooAsync();   \r\n}\r\n```\r\nThen an `await new` or `new async` shall be needed in order to instantiate the type.\r\n"},"comment":{"url":"https://api.github.com/repos/dotnet/roslyn/issues/comments/254605203","html_url":"https://github.com/dotnet/roslyn/issues/6788#issuecomment-254605203","issue_url":"https://api.github.com/repos/dotnet/roslyn/issues/6788","id":254605203,"user":{"login":"CyrusNajmabadi","id":4564579,"avatar_url":"https://avatars.githubusercontent.com/u/4564579?v=3","gravatar_id":"","url":"https://api.github.com/users/CyrusNajmabadi","html_url":"https://github.com/CyrusNajmabadi","followers_url":"https://api.github.com/users/CyrusNajmabadi/followers","following_url":"https://api.github.com/users/CyrusNajmabadi/following{/other_user}","gists_url":"https://api.github.com/users/CyrusNajmabadi/gists{/gist_id}","starred_url":"https://api.github.com/users/CyrusNajmabadi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/CyrusNajmabadi/subscriptions","organizations_url":"https://api.github.com/users/CyrusNajmabadi/orgs","repos_url":"https://api.github.com/users/CyrusNajmabadi/repos","events_url":"https://api.github.com/users/CyrusNajmabadi/events{/privacy}","received_events_url":"https://api.github.com/users/CyrusNajmabadi/received_events","type":"User","site_admin":false},"created_at":"2016-10-18T18:58:18Z","updated_at":"2016-10-18T18:58:18Z","body":"> To equate them is disingenuous. \r\n\r\nThis is also circular.  \r\n\r\nWe've made hundreds of decisions in the language that make certain constructs behave more similarly to other constructs.  At every point, we could have make the argument to not do so because, well, they were different constructs.  However, we ended up still doing so because we felt that the differences were not sacrosanct.\r\n\r\nNote that this has caused consternation in the past.  For example, Nullable's break with 'structs' (such that it boxes into 'null') was a huge contentious point, with tons of people arguing against it.   Similarly, the ability to call a static method with what appears to be an instance method was vehemently opposed by many.  In these cases though we looked and felt that there were substantial benefits with understood and acceptable downsides.  \r\n\r\nRight now, i'm feeling the same way for async construction.  Can it be abused?  Of course.  So can operators (another thing many hate), and so many other things.  Can it be used effectively?  Definitely.  The question is: is there enough value in their effective uses to warrant it.\r\n\r\nRepeatedly going to the position that this is just, ipso facto, bad is not conducive to a good and healthy discussion on where the language should go.  \r\n"}}
{"actor":{"display_login":"CyrusNajmabadi"}}