Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 04:29
    typescript-bot synchronize #34503
  • 03:08
    Meir017 edited #34617
  • 01:13
    typescript-bot synchronize #34503
  • 00:42
    amcasey review_requested #34631
  • 00:42
    amcasey review_requested #34631
  • 00:42
    amcasey opened #34631
  • 00:42
    amcasey synchronize #15575
  • 00:42
    amcasey synchronize #28460
  • 00:42
    amcasey synchronize #31641
  • 00:42

    amcasey on master

    Stop pre-emptively creating dir… Inline function to tidy up cont… Update another writeFile call-s… and 5 more (compare)

  • 00:41
    amcasey closed #34521
  • 00:00
    typescript-bot closed #33800
  • 00:00
    typescript-bot closed #33859
  • 00:00
    typescript-bot closed #33928
  • 00:00
    typescript-bot closed #33946
  • 00:00
    typescript-bot closed #34540
  • Oct 21 23:22
    amcasey synchronize #34521
  • Oct 21 23:20
    ahejlsberg milestoned #31006
  • Oct 21 23:20
    ahejlsberg demilestoned #31006
  • Oct 21 23:15
    ahejlsberg demilestoned #27118
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
AnyhowStep
@AnyhowStep
class A {
  x! : number
}
class B {
  y! : number
}

//Neither A nor B, nominally
//Is A, structurally
const aOrB : A|B = { x : 32 };

if (aOrB instanceof A) {
  const a : A = aOrB; //OK
} else {
  const b : B = aOrB; //Expected to fail; is OK
}
Bruce Pascoe
@fatcerberus
So instanceof does narrow in the false branch
AnyhowStep
@AnyhowStep
I wonder if there's an issue
Asking to "fix" this
I could find anything
I used "instanceof narrow false branch"
Bruce Pascoe
@fatcerberus
Definitely think classes should have been all nominal all the time, but I'm realistic and realize that's not possible to change now
Plus it would differentiate class from interface typing-wise
AnyhowStep
@AnyhowStep
I guess I'll open an issue and wait for it to be closed as duplicate or working as intended lol
Bruce Pascoe
@fatcerberus
Haha