Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:55
    falsyvalues opened #34592
  • 09:51
    blixt opened #34591
  • 08:25
    OliverJAsh edited #34590
  • 08:23
    OliverJAsh opened #34590
  • 04:19
    typescript-bot synchronize #34587
  • 02:48
    btoo edited #34589
  • 02:41
    btoo edited #34589
  • 02:40
    btoo opened #34589
  • 02:12

    rbuckton on optionalChainingPerf

    (compare)

  • 02:02
    rbuckton review_requested #34588
  • 02:02
    rbuckton opened #34588
  • 02:02
    rbuckton review_requested #34588
  • 02:02
    rbuckton review_requested #34588
  • 01:58

    rbuckton on fix34579

    Propagate 'undefined' instead o… (compare)

  • 01:05
    typescript-bot synchronize #34587
  • 00:46
    typescript-bot opened #34587
  • 00:36
    DanielRosenwasser labeled #34583
  • 00:36
    DanielRosenwasser synchronize #15575
  • 00:36
    DanielRosenwasser synchronize #28460
  • 00:36
    DanielRosenwasser labeled #34542
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
AnyhowStep
@AnyhowStep
AnyhowStep
@AnyhowStep
image.png
There are way too many ways to fetch a value from a database >.>
fetch-all-unmapped is the base "fetch" function and everything else is just a convenience function
AnyhowStep
@AnyhowStep
I haven't even worked on pagination and cursors yet
Shanon Jackson
@ShanonJackson
why not just...
import * from "./fetch"