Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 19:15
    orta synchronize #28460
  • 19:15
    orta synchronize #31641
  • 19:15

    orta on master

    Update the README links Merge pull request #34648 from … (compare)

  • 19:15
    orta closed #34648
  • 19:04
    typescript-bot opened #34681
  • 18:59
    typescript-bot synchronize #34506
  • 18:59
    DanielRosenwasser closed #34680
  • 18:58
    DanielRosenwasser reopened #34679
  • 18:58
    DanielRosenwasser closed #34679
  • 18:52
    typescript-bot opened #34680
  • 18:51
    orta labeled #31155
  • 18:41
    DanielRosenwasser closed #33742
  • 18:29
    RyanCavanaugh synchronize #15575
  • 18:29
    RyanCavanaugh synchronize #28460
  • 18:29
    RyanCavanaugh synchronize #31641
  • 18:28

    RyanCavanaugh on master

    Prioritize loading plugin from … (compare)

  • 18:28
    RyanCavanaugh closed #34656
  • 18:28
    RyanCavanaugh closed #34616
  • 18:17
    weswigham review_requested #34679
  • 18:17
    weswigham review_requested #34679
AnyhowStep
@AnyhowStep

function takesNumberOnly (x : number) {
  console.log(x+1);
}
async function returnPromise ()  {
  const x = await 1;
  takesNumberOnly(x);
  takesNumberOnly(await 1);
}
If (await 1) is an expression of type Promise<number>
Then the second call to takesNumberOnly would not work
Gareth Jones
@G-Rath
Yeah I see. and you're right; this is turning how I figured it would
it's contextual, but too complex to type like that
AnyhowStep
@AnyhowStep
It's sytactic sugar for,
function returnPromise2 ()  {
  Promise.resolve(1)
    .then((x) => {
      takesNumberOnly(x);
      Promise.resolve(1)
        .then((y) => {
          takesNumberOnly(y);
        });
    });
}
Gareth Jones
@G-Rath
yeah yeah
AnyhowStep
@AnyhowStep
gdi gitter highlighting
Gareth Jones
@G-Rath
you need to add ts
im actually slightly disppointed in myself for not putting that together XD
but cheers for the sanity check
AnyhowStep
@AnyhowStep
Sometimes, adding ts doesn't make it any better =x
No problem <3
Gareth Jones
@G-Rath
yeah I know
but so yeah: it's b/c of the await in the inner fn
also ugh ffs my whole fn is redundant XD which is annoying b/c I thought that originally :joy:
AnyhowStep
@AnyhowStep
I didn't even notice till you said it =x
I need to up my code review skillz
Bruce Pascoe
@fatcerberus
(await 1) is expression of type number
It auto-wraps 1 in a promise and then unwraps it
You basically just waited an extra tick for a value you already had :P
AnyhowStep
@AnyhowStep
Kick him down some more :soccer:
Derya Aydede
@Derya
is async/await actually just syntactic sugar?
i was under the impression that it actually is not the exact same as the non-async equivalent

Without await, promises in for loops would be a hassle, especially if each iteration depends on the previous iteration (so no Promise.all())
I think you have to actually use a recursive function for the loop if you can't use await.

Memory is rusty and I'm too lazy to try it out

Derya Aydede
@Derya
yeah you'd have to make some nightmarish construct
thank you based async/await
Bruce Pascoe
@fatcerberus
It’s syntactic sugar as far as the behavior goes, but it being syntax makes it a lot easier to write certain constructs, like AnyhowStep says
The main advantage is you can use the value of a promise at expression-level
Whereas with .then() it’s just one step above callback hell
But other than that it's still just vanilla promise semantics under the hood, right down to the duck-typed .then
The best way to describe it is to imagine the async function is a generator, and await does something like Promise.then(x => currentGenerator.next(x)); yield;
Bruce Pascoe
@fatcerberus
Destructuring in function parameter lists still confuses the hell out of me: microsoft/TypeScript#33474
I look at the signature and it's like... okay... now exactly what am I supposed to provide at the callsite for that
I have to mentally reconstruct the destructuring in order to know what to pass to it
AnyhowStep
@AnyhowStep
Fuck that mess lol
Bruce Pascoe
@fatcerberus
I don't see how using the nightly helps, nightlies don't include unmerged PR features do they?
Bruce Pascoe
@fatcerberus
https://github.com/microsoft/TypeScript/issues/33475#issuecomment-532443362 - writing this up made me realize that classes should really always be nominally typed (even if there are no private properties) because of instanceof
obj instanceof B doesn't imply obj instanceof C at runtime
Guess that horse left the barn a long time ago though
Austin Cummings
@austincummings
@fatcerberus I thought the same thing when I was working on microsoft/TypeScript#32774.
Austin Cummings
@austincummings
...WRT nominal classes and instanceof
Shanon Jackson
@ShanonJackson
without providing any examples i feel like that would break interface same-name-as-class extension types
AnyhowStep
@AnyhowStep
One potential problem I might have with that narrowing is that it's possible to have A|B and then fail the A test and have it narrowed to B, even though it isn't B because it structurally matches A, just doesn't have the right prototype
@austincummings does your PR address that? =x
Like, if it fails the A constructor test, it shouldn't narrow in the false branch. Should still be of type A|B, imo
Because it looks like that test rules out the nominal side but not the structural side
Bruce Pascoe
@fatcerberus
Does instanceof behave that way now?
Because his test is basically just a different way to do an instanceof check