Prior Art?

[rickbutton]

trafficstars

I did some preliminary digging, but could not find any prior art in other languages for async constructors. Obviously, tons of prior art exists for factory functions / private constructors, especially in languages with static typing, but I've failed to find any mention of explicit async constructors in any other language.

Prior art here would be very useful if wanting to justify async constructor() specifically.

[bmeck]

In general there are a very large variety of ways that people do async initialization and there is plenty of work on prior art and opinions on what makes the differing patterns of static methods, private constructors, factories, etc. better than each alternative. I think the goal here is to find what is best about the approaches to take a step forward. I don't see anything as being able to be dismissed purely based upon lack of prior language art. For example, if async constructor is just sugar for one of those patterns I don't think it is problematic to use that as a syntax. Perhaps clarification on why async constructor is problematic as a syntax and thus not good for any form of semantics. Is the argument that we must adopt the semantics of another language's syntax being what is discussed?

[wentout]

I'm very sorry if this comment is offtopic. Though it is very important to me, because async init is very close to understanding of Control Flow itself, and, therefore it might be very tightly related to monitoring and other features which we have as a sort of side effects. But, from other side there might also be implementations of something "clean" enough to say "clean async function". For example, I might be having a library or framework which is based on a prototype chain and I might be doing chaining of asynchronous constructors, and this is my app topology. So, I think it is very close to Railway Orientied Programming, where we have a monad concept. And that is why we might be seeking there for asynchronousity. And I also think this is very close to this upcoming PR as an indeep concept of underlying of supplementary utilities of why this idea is important.

[rickbutton]

@bmeck I don't want to dismiss anything due to lack of prior art, and don't find it problematic as syntax. Since this is largely an argument about ergonomics, I am interested in prior art around async constructor in order to evaluate whether it ended up being ergonomic/useful in other languages, or if other classic methods (static functions, etc) are more common.