Is there any update as to when this might make it into the rescript package itself? Assuming that’s eventually the idea.
There are plans on shipping it in the next few weeks, but probably in a different way than originally planned. We want to take a chance to gracefully improve the Js namespace situation, that’s why it will take a little longer than expected.
7 Likes
Excellent, looking forward to it! I’m planning on transitioning a few things to it, but I’d rather wait until it’s in the package itself, so 
that it’s hopefully available within a few weeks.
2 Likes
No plan to add map and flatMap to the API at least as alias to thenResolve and then? I know this is not inside Belt’s namespace but inside Js’ where the goal is to keep as close as possible to JS names, but still would be nice to have the choice so you can keep coherent names in your code base.
@tsnobip no plans on doing that, but should be relatively easy to extend the provided Promise module with your own aliases in your app code. Library maintainers need to stick with our then / thenResolve conventions to stay lean.
Also let’s wait for the upcoming async story plans before getting back into this bikeshed again 
6 Likes
Yeah really looking forward to that, to me it’s the last pain point remaining in rescript projects, so much has been done already to make development in rescript an amazing experience!
2 Likes
Excited that this is shipping soon! Looking forward! 
I have a question about Promise binding.
Because it seems most libraries didn’t discuss about Promise.allSettled the new binding would be a good place to start.
The result of executing allSettled is Fulfilled('value) | Rejected(reason)` variants and I don’t think a zero-cost abstraction is possible for this.
Does this mean that official binding can intentionally silentt on some standard functions and leave them to user-level abstractions?