FTR, TypeScript and Flow (I assume) know when the static type of a function
call (or any other expression that evaluates to a Promise) is a Promise,
and if you try to use it as if it wasn't, it will almost surely be a type
error.
On 12 February 2018 at 10:27, Алексей wrote:
> I think there is so
On Mon, Feb 12, 2018 at 11:27 AM, Алексей wrote:
> I think there is something we could have right now to solve the problem of
> missing `await` without changes to the ES - it should be collored
> differently in IDE or texteditor you are using. Not like an error - because
> it's actually not. But
I think there is something we could have right now to solve the problem of
missing `await` without changes to the ES - it should be collored
differently in IDE or texteditor you are using. Not like an error - because
it's actually not. But to be obvious that "here" and "here" you have an
`async` fu
Um, no the increased rate of productivity is in converting
```js
getUserInfoAsync()
.then(
userInfo=>{
//Do stuff with userInfo
}
)
```
into
```js
const userInfo = await getUserInfoAsync();
//Do stuff with userInfo
```
...allowing complex async data flows to
I fail to see the increased productiveness by converting:
FunctionExpression => function FunctionSignature Block
To:
FunctionExpression => async function FunctionSignature Block
And the equivalent for the grammar for await. Probably:
UnaryExpression =>
await RealUnaryExpression
Or somethi
You've lost me. It's not intended to add logic. It's a replacement for
callbacks, and makes expressing async data flows simpler & more manageable,
allowing more complex async data flows to be expressed more quickly and be
less prone to bugs. The `autoasync` `background` concept makes this even
more
On Thu, Dec 7, 2017 at 2:34 PM, Naveen Chawla wrote:
> How has using async await made you type more? Can you give an example? I
> suspect you're not using it in the way it was intended to be
>
See example OP pasted. It's nothing but async/await. It doesn't add any
semantic, syntactic or logic th
How has using async await made you type more? Can you give an example? I
suspect you're not using it in the way it was intended to be
On Thu, 7 Dec 2017 at 16:15 Florian Bösch wrote:
> as I predicted once you use it, await/async infests all calls/funcdefs,
> and has now become pointless line-noi
> On Dec 7, 2017, at 5:50 PM, Isiah Meadows wrote:
>
> The real solution to that would be stackful coroutines, but those are tricky
> to implement and are substantially slower at lower nesting levels. (Go's
> goroutines are built from this under the hood.) There's tradeoffs to be made.
that i
The real solution to that would be stackful coroutines, but those are
tricky to implement and are substantially slower at lower nesting levels.
(Go's goroutines are built from this under the hood.) There's tradeoffs to
be made.
On Thu, Dec 7, 2017, 05:45 Florian Bösch wrote:
> as I predicted onc
as I predicted once you use it, await/async infests all calls/funcdefs, and
has now become pointless line-noise that you need to remember to write or
you will get into trouble, but serves no discernable semantic, syntactic or
logical function other than making you type more.
solution: write a tran
@isiah thx for link and read the article (i actually enjoy reading most of the
links you post on this mailing list).
we can agree to disagree - i've been using recursive-callbacks for 5 years now.
they’re quite powerful and elegantly solve the callback-hell issue.
recursive-callbacks can do pr
Kai, please read [this article][1]. Also, please stop filling your
emails with walls of code - it makes it *much* easier to comprehend.
If you feel the need to post pictures, please find an image hosting
service or something. If you feel the need to show large amounts of
code, please try using GH G
> with the added bonus of transparently allowing sync functions to be
converted to async functions without fundamentally affecting consumer
calling code.
It does fundamentally affect calling code if the calling code reaches
outside of its local variables. The state of the world around you might
ch
Steven, this is a replacement for `await` `async`, and makes `await`
`async` redundant. There is no point teaching `await` `async` if you can do
`asyncauto` and `background`, just like there's no point teaching `var` if
you can do `let` and `const`. It should be a clean break. Otherwise it
introduc
Obviously. The whole point of this proposal is that awaiting async
functions is automatically _implied_ inside an `autoasync` function, unless
an async function is called with a `background` qualifier (which thereby
makes it return its promise instead). The OP is right: this is a far less
bug prone
Am I misunderstanding something about this proposal that it's substantially
any different from `.then` or immediately invoked async functions?
```js
// Original
await function foo() {
const bar = async baz()
use(bar)
}
// What I'm reading
function foo() {
;(async () => {
const
On Mon, Dec 4, 2017 at 2:37 PM, Bob Myers wrote:
>
> It turns out that this approach has a number of problems.
> As a result, future versions of selenium will no longer support it.
> Test writers will be asked to write `await` where needed.
Were there problems other than the complexity of maintai
It might be useful to consider the `ControlFlow` notion used in writing
selenium tests.
All the steps in a test routine, which appear synchronous, actually
implicitly introduce the equivalent of promise/then structures.
They took this approach because almost all such integration tests are
asynchron
Apologies for the double-post. I meant to end with:
**All of that said**, you are talking about opt-in behavior. And that makes
it an easier sell in many ways. Doesn't make it less confusing having two
competing async syntaxes, and I think that's a major issue, but with the
opt-in at least I know
On Mon, Dec 4, 2017 at 12:52 PM, Steven Mascaro wrote:
> 3. I think the principle "prefer explicit to implicit" argues in
> *favour* of the proposal (and against the existing syntax).
> You gave the example:
>
> ```js
> let x = foo();
> let y = bar();
> ```
>
> Imperative language conventions impl
Oh, and just to be clear, there would still need to be an explanation for
why you need to attach `async` or `await` to any function that contains a
call to an asynchronous function. I assume that requirement exists for
performance reasons --- I have suggested that requirement be dropped
elsewhere,
Thanks Naveen, I agree, potentially in full.
Let me address T.J. Crowder's objections out of order (2,3,1), as the
response will be clearer that way.
2. As Naveen noted, this is a use case that I did (and very much intended
to) handle in the proposal by having a keyword at the call site. Namely:
The crux of your idea is: let any calls of an async function inside an
async function automatically await unless explicity instructed to run "in
the background". I like the idea. I just wouldn't use the words "await" and
"async" for it, because they are used as currently in C#.
On the last disagre
I understand the motivation, but I have to disagree with the proposal
for multiple reasons:
1. It adds too much confusion to the existing syntax.
2. If the calling code needs to call one of these new-style `await`
functions and access its promise (rather than `await`ing it), it
doesn't have a way
Sorry for making this request now (rather than when async/await was first
being formulated), but real-world use has led me to think some things could
benefit from a slightly different syntax. I also apologise if this has been
raised/discussed before, I wasn't able to find it. The proposal is most
q
26 matches
Mail list logo
