I’m curious about this statement at the end in "alternatives":
> The proposed design eliminates the problem of calling an API (without knowing
> it is async) and getting a Future<T> back instead of the expected T result
> type. C# addresses this by suggesting that all async methods have their name
> be suffixed with Async, which is suboptimal.
Not that I necessarily think always returning Futures would be good (or bad),
but it seems to me like since we’re required to use the “await” keyword now,
we’d just have some similar keyword in an always-Future-returning universe,
like:
let image = future makeImage()
-W
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
