it turned out it was fine

is jest bad

Promise.resolve((async () => fn())()) ?

i will continue to use whatever number best supports my position

shu: finally found the example that AMP hit: https://github.com/ampproject/amphtml/pull/15107

that diff is convincing enough for me, stage 2 sgtm, if ljharb wanna come back at end of today

shu: https://github.com/tc39/proposal-promise-try/issues/9 btw for the passing arguments thing

ok wait if you're ok with arrows why not just use (async () => fn())()

what if we let prefix ^ be a shorter way to write ()=>? Could make a lot of these arrows shorter. [but it wouldn't scale to the async case]

however, this facility of setTimeout (passing args) has proven very confusing for practitioners, so i'm not anxious to repeat it

however, this facility of setTimeout (passing args) has proven very confusing for practitioners, so i'm not anxious to repeat it

& &1 in elixir is like (a) => a

i think arrow functions and bind are both better solutions than making everything that takes a callback also accept arguments somewhere

What are your thoughts on https://github.com/tc39/proposal-partial-application?

Did I disappear from the queue?

isn't it typed differently because it's not representable as an integer?

wait why wouldn't empty input produce NaN

this is IEEE floats, math and real numbers have nothing to do with anything. "the sum of nothing" can be whatever we want

I'd need a stronger argument to convince me to return +0 when passed an empty input

Math.sum([]) === 1

hax (HE Shi-Jun): in which direction?

i'm hearing you like exploits

this doesn't prevent -0 from flowing to the wrong place intentionally

i'm hearing you like exploits

I don't find this convincing here because -0 is already in the language, and returing it from a new function just adds more places to be careful by a limited number (in the places where you are inlining this built-in).

And now we are explicitly aware about this -0, it could be even be explicitly called out in the spec by saying why we return it so that implementers don't miss it.

i mean can i hear a positive argument for why you want it to be -0

if Python returns +0, i know that ecosystem does a lot of numerical stuff and it doesn't bother them, that gives me one signal

I've relied ib it for .min/.max when I get values some values initially and then other later, so I have an "intermediate min".

As Jordan pointed out however, that doesn't work here so my main argument is "all the others do this, we should not diverge"

Well, because all the number combinators return their identity when called with 0 args

Whether +0 is not an identity of Math.sum depends on what equivalence relation you’re applying to that identity:
=== versus Object.is.

In other words, the question here is which equivalence relation we think is most useful (or least risky) for general code that needs to use Math.sum.

how do === and Object.is figure into it?

how do === and Object.is figure into it?

Duncan MacGregor said ruby experienced the opposite thing, i'd like to learn more about that

Not returning -0.0 has the weird effect that summing two arrays (1 empty) can give a different result from summing the concatenated array.

yes, that's correct. i'll make a table for it once we have one

shu: Math.sum([-0]) what would you expect it to return?

sorry being slow, meaning if you do sum([]) + sum([1]) vs sum([].concat([1]))?

If this returns +0, I think it's ok to say "we always normalize -0". But if it can return -0, than you already have to be careful about it when implementing

even if we wrote down the full algorithm, we would still need to write somewhere that it was computing full precision summation because that is not immediately obvious from looking at 100 algorithm steps

So if you have [-0.0].sum + [].sum that would give a different result to ([-0.0] + []).sum.

Does a prior “Stage 3 conditional on approval by reviewers” status retroactively count as “Stage 2.7”? Regarding proposal-array-from-async.

Ok so my position is that Math.sum([-0]) and Math.sum([]) must return the same result. I would prefer both to return -0, but as long as they return the same value I'm fine

what are the two sums? +0.0 for the former and -0.0 for the latter?

Are there corner cases in arbitrary precision arithmetic that would be useful to point out in the specification? We do that in a number of places in the spec.

agreed but I wouldn't want to use any \+punctuator escapes for anything other than identity escapes, that would be very confusing

agreed but I wouldn't want to use any \+punctuator escapes for anything other than identity escapes, that would be very confusing

it already is versioned: 2

This transcriptionist is getting capitalization right even for terms not on the slides (SharedArrayBuffer)

Duncan MacGregor: Based on our conversations in the shared structs proposal, anything that could block would also have an async counterpart that could be used in the main thread (e.g., the "async locking" primitives discussed on one of the slides).

Thanks, I think an async API for condition varialbe might work, but my experience of writing concurrency libraries and reviewing concurrent code in general is that we should absolutely aim for higher level constructs because building them correctly from lower level ones is really hard and is not something we should generally be steering developers towards doing.

since danielrosenwasser's question wasn't asked verbally, it may be worthwhile to copy it into the notes for anyone reading afterwards

apologies, didn't want to exhaust the timebox while I scrambled for the mic

Luca Casonato: do you have pointers where the move to remove the wasm handshake was discussed? I'd like to follow the developments, in particular regarding to this agent global syscall table it would likely introduce

what else are we even going to do in the remaining time before lunch though?

I think the JS proposal can be almost completely polyfilled based on the wasm one

Except syntax and the handshake complexity, and I'd really prefer we have actual syntax for this in JS.

the current proposal has no syntax, does it?

Except syntax and the handshake complexity, and I'd really prefer we have actual syntax for this in JS.

syntax, but the things produced are objects, not primitives?

handshake you can do if the library is run in the worker as well. for sure agreed that syntax would be good. this is mostly pointing out that erights' objection just does not make sense because we'll do it in JS anyway

There's one possible world where this gets implemented in Wasm and then the syntax / polyfill is (at least initially) provided via build-time tooling. In particular, because Wasm functions don't close over nearly as much state as JS functions, shared behaviour seems strictly easier / cleaner to specify and implement in Wasm.

There's one possible world where this gets implemented in Wasm and then the syntax / polyfill is (at least initially) provided via build-time tooling. In particular, because Wasm functions don't close over nearly as much state as JS functions, shared behaviour seems strictly easier / cleaner to specify and implement in Wasm.

shu: Hmm. You access the property, you get some sort of wrapper back that has a local->shared edge, and then you invoke it. Are you saying that the wrapper has the same problem?

Alternatively, couldn't the wrapper be a shared object itself?

shu: SM is working on an architectural review of shared structs. Hoping to have it ready soon, although there's been enough new information today that it will take a little bit to digest it.

I'm not as sympathetic to that ljharb

i very strongly agree with everything mark is saying right now

I realize that is maybe dramatic but it's also true and we ought to care about that cost

ljharb: that would be bad faith

I disagree with the idea that "do nothing" is "fail safe". I particularly disagree with it in light of the previous conversation; I really wish it were better understood that failing to provide a good story for parallelism on the web means the experience of using the web is notably slower than it should be, and that is a cost which is measured in small fractions of billions people's lives every day

ps if it takes 2 member companies to veto, then that means it only costs $7000 to block anything.

As we'll likely run out of time here, my thought: We should mitigate the negatives of a lone objector blocking progress. One way to do that would be to automate the re-presentation of decisions with a lone objector at a near-future meeting, allowing and expecting discussion to happen in the interim. So effectively require sustained objection to block a thing with a small minority.

does anyone remember which meeting shadowrealms was dropped to stage 2?

I think I would put it this way:

The veto process means that we say the risk of doing the wrong thing is always more than the risk of doing nothing. And that's just not true. Some things, sugar especially, doing nothing is relatively costless; some things, like new capabilities and APIs for performance, the cost of doing nothing is actually quite high.

Our process should allow seriously weighing the costs of doing nothing, and not privilege the costs of doing the wrong thing as the ultimate determinant.

bakkot: That would seem to suggest that we would need different rules for consensus for different kinds of changes. Perhaps we can use consensus to weaken consensus selectively.

I think we need to solve this in abstract, since once somebody wants to block something concrete there is no reason for them to give consensus to ignore their non-consensus

does anyone remember which meeting shadowrealms was dropped to stage 2?

well, in some way we've already been cautiously starting to do this, with non-binding polls for choices that we all agree are aesthetic/unimportant. I think this is really positive and should continue!

I think I would put it this way:

The veto process means that we say the risk of doing the wrong thing is always more than the risk of doing nothing. And that's just not true. Some things, sugar especially, doing nothing is relatively costless; some things, like new capabilities and APIs for performance, the cost of doing nothing is actually quite high.

Our process should allow seriously weighing the costs of doing nothing, and not privilege the costs of doing the wrong thing as the ultimate determinant.

yes.. voting on advancing a proposal is a very different kettle of fish compared to voting for bikeshedding-type decisions

one issue is, there isn't always a shared understanding about what's bikeshedding and what's very significant. I often find myself thinking that something is bikeshedding that others thing is very significant.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

honestly, if we did strongly decide to do something like this, I'd recommend this be done by the secretaries

do you mean by Samina, the TC39 secretary?

as pointed out above, chairing the meeting is an administrative role that allows us to facilitate topics we are neutral about while being delegates

the less noticeable we are, the better

yeah it just sounds like too much work to do this and also mediate all conflicts...

I am fine leaving the decisions which are just internationalization to subgroups, but not overall questions of API design

shu: would you mind taking a quick look at the conclusion/resolution for ShadowRealm? I want to make sure I'm not missing anything.e

foo````

is already legal, alas

foo````

is already legal, alas

…Wait, what does this parse as, again?

…Wait, what does this parse as, again?

it's JavaScript, you're supposed to be able to construct horrors

lets use r#""# like rust

Meta: do people find it valuable to get constraints for later stages, even at earlier proposal advancement meetings? I would think it is helpful.

I want a better String.raw and would consider that in scope for this proposal...

Meta: do people find it valuable to get constraints for later stages, even at earlier proposal advancement meetings? I would think it is helpful.

Isn't the point of this that you don't need String.raw with it? Why would that be in scope?

what's the exact title?

bakkot: Did you agree with my problem statement? Please feel free to edit it

https://github.com/tc39/proposal-string-cooked/issues/13

When I looked at it before, it was @```, with a n+3 backticks that must be matched, as long as its one more backtick than the number of contiguous backticks in the body.

Maybe "here documents for JS"

Maybe there are improvements that could be made for String.raw, but that won't address the main concerns this proposal seeks to address.

But if "improved template literal" it very unlikely we could have "here doc" style solution.

const myEmbeddedString = String.dedent(
``delimiter text``
    Whatever I want
    to have here
    as long as this ends with
``delimiter text``);

Maybe there are improvements that could be made for String.raw, but that won't address the main concerns this proposal seeks to address.

Not sure how it look like template string (except it use backticks :P ), a problem of here doc style is normally it only support defining end delimiter but we also need to deal with interpolation delimiter.

I think the interesting thing about the proposal is that you don't need to escape anything, with the exception being ${, but that could also be tied to the opening of the fenced string literal. The Explainer used n+1 @ tokens, but could just as easily use n+1 \ tokens, etc.

It still doesn't address \ at the end of the template, so some escaping will be needed regardless. There was a thread in Google's internal TypeScript chat group about why this case wasn't working with String.raw

Even \x20 isn't transformed? I need to pay better attention.

This is why I use swift-style in the slide, because swift style only use number of # to define both token, which IMO the simplest solution. But I don't know how others think about "simple"...

Even \x20 isn't transformed? I need to pay better attention.

if Swift style, it allow u to reenable escaping by \#x20

How do you represent that inside a string, then?

As a syntax, you don't need to limit yourself to @ and # as there are other infix tokens that could be made into a prefix token. For example, you could use \``` ... ``` to mean "I've done all the escaping I need to do at the start and end of the string"