[swift-evolution] New async keyword usage

[Wallacy]

Makes sense. But if i'm reading its right (and the original proposal too),
in this case we don't have only a syntax sugar, we actually gain another
ways to use.

First, because Future actually need another proposal, and beginAsync  (to
me) does not apear to be that rare! "Fire and Forget" is pretty common when
we use Cocoa.

Second, because in this way we don't need to handle with Future anymore.
Like i see on the other Threads, people tends to believe the "Future" is a
more powerful, and only what is needed. Because that (not only that) we
cant prevent something like this:

func someAsyncFunc() -> Future<User>


So, after the Future class be implemented, we will need to handle with two
patterns at same time! Sometime we will use "await someAsyncFunc()" other
times, we will be forced to call someAsyncFunc().get().

Using only async/await is pretty easy to learn and teach. And the ability
to only "wrap" at asynchronous context and "unwrap" using only these two
keywords appear be worth.

Use async keyword to make a function asynchronous.
Use async keyword to make a closure asynchronous.
Use async keyword at call side to capture the "reference" and only "unwrap"
later. (maybe send to some other place too).
Use await  to get the value from a async function/closure.

And after that, "Future" can be implement in any way because will not be a
public API anymore (I do not know, but there may also be some opportunities
for optimization as well), and we only need to care about when we need to
"keep the reference" from some async call.

And possibly, they will not need to create any Future type! The variable
type will be "async User" as long as it is not "unwrapped". (
suspend/defer/abandon still possible)

Em sex, 25 de ago de 2017 às 02:15, Chris Lattner via swift-evolution <
swift-evolution at swift.org> escreveu:

>
> On Aug 24, 2017, at 4:40 AM, Trevör ANNE DENISE via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hello Swift community,
>
> I was really interested by the recent* Task-based concurrency manifesto*
>  and *Concrete proposal for async semantics in Swift.*
>
> Looking at beginAsync() and Futures, I had an idea for a new syntax based
> on the `async` keyword, I'd love to hear your feedback about this idea:
>
> https://github.com/adtrevor/Swift-ideas/blob/master/New%20async%20keyword%20usage.md
>
> Would such a syntax make any sense?
>
>
> Yes, it is entirely possible that we will want to provide more syntactic
> sugar than the proposal suggests: the proposal is intentionally designed to
> be minimal, so we can get it in place, get experience using it, then decide
> whether any specific syntactic pain point is significant enough to be worth
> adding additional sugar/complexity.
>
> As has been mentioned in other threads, the hope is that “beginAsync” is
> actually extremely rare in practice.  If that is the case, there is little
> point to sugaring it.
>
> -Chris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170825/0c7c64d0/attachment.html>