Myles C. Maxfield

Resolved this week: Reject the promise (with nothing) if compilation failed.

I have pretty serious concerns about the "with nothing" clause above, because if the promise is rejected with nothing, the author won't get any error messages, which means they won't...

Our position on this: - If the invalid constexpr expression involves an out-of-bounds access, then it should be a compile-time error. The author is bad and they should feel bad....

> If the invalid constexpr expression involves an out-of-bounds access, then it should be a compile-time error. The author is bad and they should feel bad. This is actually super...

> `arcsin(2)` Note the spec right now doesn't define what this returns.

First of all, it's good that so many functions are non-NaN over ~all of their domain. It looks like these operations produce NaN for roughly half of their domain, or...

I split this out into https://github.com/gpuweb/gpuweb/issues/3365 which I believe blocks this issue.

Imagine the above program was slightly modified to replace: ``` bufferA.mapAsync(...).then(...); ``` with ``` bufferB.mapAsync(...).then(...); bufferA.mapAsync(...).then(...); ``` This "in-flight count" proposal would make it possible for `bufferA`'s promise to resolve...

This probably has to be discussed for V1 because changing the order of promises could break production code.

I'm confused. I don't recall any optional feature being discussed on this topic at all during the previous call. The minutes seem to agree: https://docs.google.com/document/d/1dKRliRWimQzmYswAY_SkQZnQdNYwD7HVgCCPF2hBItw/edit#heading=h.7rkxrt7w5cyr Are you sure you didn't...