bakkot: looks like we're missing the logs for today? https://matrixlogs.bakkot.com/TC39_Delegates/2023-07-11

the end goal for me is users, not developers, and good defaults for me should be chosen to nudge developers to the result (responsiveness, correctness, fast loading, whatever) we want on products they build for the user. if all developers ignore a default constantly, then we obviously failed and nobody benefits. Google-internally, i did not get this sense when talking with practitioners about a lack of a defer-like thing

but since then we've learned that maybe that doesn't have quite the effect we hoped because people ignore it

If dayOfWeek returns 2, indicating this is the 2nd day of the week relative to the firstDayOfWeek, it could be confusing that both are numbers 1-7 but don't represent the same value.

ryzokuken 🇳🇴: yes, there is a spot for you to do so already

also, it would be safe to add later, right?

Bradford Smith: yes, and views should be very lightweight

I think the streaming design is as fleshed out as it's going to be, we just need to decide whether it's justified for inclusion or not

should

there are a lot of APIs that don't handle binary data at all. You can only send e.g. images via encoding

re: streaming: I think, in general, it's vaguely best practice that primitives that deals with data should have zero-copy and streaming APIs for doing stuff with them. To me, the main question is whether there are valid use cases for doing base64 on a fairly big thing that can't fit in memory/packets all together. I don't know of such use cases/environments.

for using Symbol.enter as a way for types to enforce they are being assigned to using, could this also be done with Symbol.dipose setting a userHasAcknoledgedLifetime flag that either errors/warns if other methods are called without that flag set?

my gut feeling is also that DisposeStack.p.return is a simpler API to explain that the enter/exit symbols.

Regarding the GC cleanup issue: I thought Ron was suggesting that engines could be encouraged to clean up any disposables that they themselves created (not every possible disposable) if they go out of scope without "leaking" anywhere else from the scope where they were created.

Yes, a user-defined implementation could conceivably make [Symbol.dispose] a getter that indicates the method was at least read.

sorry, move

Personally, I think you're chasing an impossible goal here. The Explicit Resource Management proposal as-is provides a useful feature. There's no need to try so hard to force its correct use. Leave that problem for another day. Just my $0.02.

for the examples where code is switching if the exit was a throw or return completion. Reaching DisposeStack.p.move also indicates that

I'm not convinced we even need [Symbol.enter]().

I think we should conclude that we're not going in this Symbol.enter direction

I am not a politician, I do not get to decide that

bakkot: the DPRK makes their own OS

I think the details of whether engines ship the Intl-only part separately or just together with Intl is something that we can leave to engines to decide. If an engine expects to take a really long time to do Temporal, they might do the Intl-only part. But Temporal should only ship with this included, and it'd be valid to ship at the same time. Within this, I think 2a would be the simplest way to organize the explanations.

that's what I was getting at, but I take Shu's point that that causes interoperability problems

however, no real program relies on hoisting import declarations, because that's batshit

hm, can you class extends AbstractModuleSource { } if it's not constructable or callable?

Yes but you cannot then call super()

(hoisting in the function declaration sense, that is)

really? you don't write mutually recursive functions?

not that nobody relies on the hoisting function semantics, but the hoisting import semantics that are like the hoisting function semantics

not that nobody relies on the hoisting function semantics, but the hoisting import semantics that are like the hoisting function semantics

it's unconditionally throwing now but the comment suggests otherwise

It's pretty common to use function hoisting in a sillier way, like

foo.onbar = fn;
function fn() { }

In fact, fear of breaking this particular pattern is what's holding back function decorators

sillier? This is a common practice in the TS codebase, i.e.:

function createFoo() {
  const quxx = ...;

  return {
    bar,
    baz,
  };

  function bar() { ... }
  function baz() { ... }
}

someone is typing loudly again

someone is typing loudly again

Do y'all think that throwing only if constructed directly would be an acceptable solution?

did it stop for you?

it seems important to be able to self-host in JS tho

you could with on-the-fly source rewriting, no? i don't mean virtualization which indeed would require custom module loading

If you're rewriting source, why do you care about using a real source object at all?

'source' is much easier to write and spell than 'instantiable'

sorry, which sorts of interactions are you picturing?

importing and using wasm is power user now?

(like, what do you think you want to do with the thing you get from this phase, if not to instantiate it later?)

import raw

But how often is this word getting typed out?

do we imagine using this for things other than wasm

that suggests maybe import.reflect?

maybe the answer is there is just no intuition for half-processed things having names

import sauceable?

I would unironically support sauce

we do have some time available tomorrow if folks would like to have further discussion regarding source phase imports naming

parsed i can live with but wasm isn't parsed but validated?

maybe come back and see if import parsed is amenable to everyone?

oh that is lovely to hear! i hope we can work more with the community there, they are very excited about tc39

IEEE standards are paywalled?

you and i disagree

"vastly compelling" always subjective. There's almost no public JS event I've been to where nobody was lamenting IEEE doubles.

What amount of developer demand would convince an implementor, that an implementation is worth the burden?

As I have stated before, we were using -> https://mikemcl.github.io/decimal.js/ - I do not care about IEEEEEE4673838 as a developer, I just want something that works™, preferably from my good olde JS engine! :)

and without being primitives, what's the value over just using a library - "i don't have to install it" imo is far far weaker than "it's more ergonomic"

Jesse (TC39): do you want to have a continuation for Decimal tomorrow? if so, how long?

Re: the Decimal proposal, do I understand right that as currently proposed 1.0m === 1.0m would be false, yes? That's... weird.

but numeric literals having Object semantics feels it is unprecedented in all of PL. would be fascinating to see an exception

i.e., make === be numerical equality when both lhs and rhs are Decimals

i would not support this

in C# (a language that has decimals natively), you use a cmp function (returns -1, 0, or 1), which is also what I have in my current proposal. No ===