Comment by yarg

I really don't see the need for such a syntax. If I say:

  Foo foo = someFoo();
  ...
  String content = foo.getContent();

I really don't care if foo was returned when I called someFoo(), I only care that getContent() is not attempted until after foo is defined.

There's little reason for me - in this situation at least - to need this async functionality to be explicitly stated.

The biggest problem I see is a when you use this functionality in a loop of independent executions (when the results of any given loop don't depend on the results of prior loops):

  for(Foo foo: asyncFoos()){
      Foo foo = someFoo();
      ...
      result.add(foo.getId(), foo.getContent());
  }

The problem here is that the use of a for loop will introduce latency, potentially dramatically increasing execution time.

Now you can either replace this "for" with some sort of "for-each" type of block, or you can go async all the way and treat "for" as "for-each" and any referenced result of a prior iteration as yet another async value.

That covers sets and singletons, I imagine that any other situation that needs to be dealt with can also be covered on the compiler side of things with only minimal changes to syntax.