Nothing public no. My guess is that it’ll probably land initially without much warning, like function builders or property wrappers. Property wrappers being a good example of a feature that was previously proposed that came back (somewhat) suddenly. Initially it was proposed as property behaviors, although they accomplish largely similar things.
But all we can do is speculate if there isn’t going to be a community driven effort to get it implemented.
is this the only place where concurrency topics are discussed? IIRC the kickoff for async/await, etc discussions was in 2017 and now is almost 2020, and it doesn't look heavily discussed here (unless there is a secret channel of course) and languages like kotlin that started later already have it but not us, and languages that started earlier can give us some great kickstarter ideas so we don't have to do everything from scratch?
until it is in the language, can anyone explain me in one or few lines from a bird view perspective, and from a user point of view -- what will be the massive benefits of this language feature compared to using one of the libraries in the wild that claim to provide coroutines / async/await today (i will not name them but there are a few). is that the quantity aspect, for example with those libraries i can create, say 100K coroutines while with the language ones I can have 1M or what?
I tend to agree with some of this. It may just be a lack of effort on my part, but I find that I have no idea about what is planned/being implemented. Sure, there are manifestos and sometimes a person pops up saying that the core team is currently focused on the ownership model, but that’s about it. Is there a way to find the current state of these efforts? The development of Swift is largely guided (controlled even) by the core team, but we have little insight into what is actually happening. It is quite frustrating to be left in the dark like this. Or am I missing something? Is there a page similar to the evolution proposal status for more long-term goals?
True but that requires the core team to focus some mental energy and effort into keeping us updated. I've been wondering if there's a niche opportunity for someone interested in journalism and technology to just be able to poke their mind and release weekly or even monthly news/interviews. It's a way for that person to gain visibility if they're able to make quality content and for the team to be able to keep us updated without expending much mental energy on it.
Disclaimer: I'm not interested in journalism myself, it's just an idea.
That's fine and could even be automated to be turned into a feed on a website, but that's assuming no one is working on features in a local branch in their PC that don't get pushed into the repo for a long time(or using other remotes). Is that the case?
If you can't see the commits for any reason, they may as well not exist. There's no point at all in worrying about them, and there's no reason to expect to get any kind of regular updates about the status of such forks.
I don't believe there have been any substantial additional discussions - there have been some underlying changes, and more are obviously needed. The focus for 5.x so far has been API stability, binary compatibility and module stability. 6.0 has not yet been started, so there is not yet a stated focus.
I would more items from the ownership manifesto, especially coroutines, to be added before async/await.
I expect there to be influences from LLVM's support for coroutines, C++ coroutines, Rust's async/await, and Objective-C callbacks as well as Actors from languages like Erlang.
Coroutine support in the compiler will likely enable optimizations including inlining coroutine code and reducing copying/reference counting. Coroutine libraries today likely all use thread pools (such as via lib dispatch), spinning the task off to another thread. This adds additional concurrency overhead and concurrency-related issues - coroutines themselves as a language feature will likely not rely on threading themselves at all, and may behave as value types. The scalability will be far better.
Also, first-class language support will likely have better syntax.
Longer term, it is possible features like actors might provide isolation, such that things like a precondition failure terminates an actor rather than the entire process.