oooohhh I like this history slide a lot

It would be surprising if Node and Deno really continue to not support this when Chrome does

(I deleted Michael Ficarra's comment accidentally)

not literal === equality but equality methods

IIRC, equality has always been a top-level goal?

I've long been in favor of the introduction of user-defined value types, and it was one of my goals for structs

I think when we drop equality, the argument for value types is weaker

I am very interested in multi-key maps...

I think when we drop equality, the argument for value types is weaker

Operator overloading here is not user defined

Without === there is little value add; as in just use immutable.js and be done with it.

but === already be overloaded by different primitive types and objects?

I guess it depends on how you see R&T. If you say "R&T are like objects", then giving them a different equality feels different from how other primitives have their own equality

The real problem is who can represent developers.

littledan: I've been thinking about the "dynamic comparison in Map/Set" thing for awhile, and started working on a draft of a proposal awhile ago.

We have many delegates that are JavaScript developers and not just standard/engine engineers

I don't quite understand what alternative Yulia has in mind, and I'd like to know what it is.

https://gist.github.com/rbuckton/f8c2ac278b796324a06410e59c56eb10 (4 years old at this point)

Thanks for sharing this!

I don't quite understand what alternative Yulia has in mind, and I'd like to know what it is.

I don't have 100% a full solution, I would like to see an investigation of building this on top of shared structs or a clear problem statement. so far it is usually a compound description of the constraints that lead us to a primitive, but many of them are issues i see more broadly in the language and i think would be beneficial if expanded

Fwiw here is another gist around an alternative, trying to draw out how there really is a spectrum of options https://gist.github.com/littledan/4b9c797f3e70d3531fcf32decc6e9754

I think i outlined a couple of things that might work? and also the conditions that would resolve our concerns. I am not sure what you are asking

its another thing if you don't like the solution, I still consider them valid and the implementer concerns are significant. I wouldn't bring this up otherwise

In part the goal today was to also bring the concerns we have already discussed among champions and implementers to the broader committee, so we are sort of going over ground a second time -- what I am saying now is not substantially different from our prior meetings

though I guess symbols as weakmap keys make that less necessary

what does "kicker" mean here?

I'm not saying I have no interest, but overriding equality/hash for Map/Set is a much higher priority to me.

As discussed earlier today re Intl.Locale, I wonder if this is true?

const src = ...
new Module(src).source === new Module(src).source // ???

it's a new kind of eval, you can't use dynamic eval to evaluate an arbitrary string

as dan said on the queue, i can eval(`module { ${source} }`) anyways, how is that different from passing source in directly?

Luca Casonato: assuming foo.source is opaque, yes, I think so

though, I should say, I also don't understand the need for that

what about feature-detection? like "is TLA supported"

Right but engines can guarantee the stability of this, where delegating to the program, I don't see how it can

right, but how could i detect it if i can't make a module from a string

what about feature-detection? like "is TLA supported"

eg i want to know if it's worth trying to import a module that i know requires TLA support, and i support envs that lack it, and i don't want to even bother making the network request if it lacks it

Would you not generally know this up front, given that its usually unsafe to eval code you don't control anyways?

ljharb well, nothing is going to have ModuleSource but not TLA, so presumably you're imagining some other syntax?

(altho ModuleSource can probably be polyfilled since every engine has a way to create ESM from a string, despite it not being in 262)

do browsers have a synchronous way to do this? I thought not

i'd know that the code i'm importing has TLA, of course - but i don't know what the env supports

I assumed implementations would care as it would allow user code to execute in the middle of internal Map/Set implementations. This is also a problem for the Map user if the equality somehow further delegates to the objects themselves.

yes i agree, but i'm saying that you can not perform that feature testing in the first place without this capability

we shouldn't be encouraging them to do equivalent things

I want constant time, make it happen

I'm finding the fact module importing a ModuleSource and not a Module slightly confusing from the perspective that the keyword isn't quite aligned to the type.

I'm finding the fact module importing a ModuleSource and not a Module slightly confusing from the perspective that the keyword isn't quite aligned to the type.

I'm finding the fact module importing a ModuleSource and not a Module slightly confusing from the perspective that the keyword isn't quite aligned to the type.

I am encouraging a return to the consideration of import moduleSource from './example' with { reflect: true } to mirror the proposed dynamic import. This is consistent with a need to confine dynamic import and washes back from that.

like I think of the regular import statement as importing a module

That’s very reasonable, though it doesn’t provide any reflection of that module.

i really don't like the "with" object, or any object form. are there long term, concrete, viable plans to add something else to the object?

okay I think I finally understand why this doesn't solve deferred evaluation: the deferred eval use case still wants to load the whole module graph eagerly, right? just not start evaluating?

okay I think I finally understand why this doesn't solve deferred evaluation: the deferred eval use case still wants to load the whole module graph eagerly, right? just not start evaluating?

nicolo-ribaudo: wait, doesn't omitting the handler get you what's equivalent to the host?

Kris Kowal: why isn't it the case that a new Module that have the host default handler get the [[HostDefined]] slot?

is this the last item

Nicolò of course is the authority on the proposed spec text, but the intent is that the Module carries host-defined import behavior and ModuleSource carries host-defined origin information and those are separate concerns. The latter would prevent import in a no-unsafe-eval for a ModuleSource constructed from text. The former defines link behavior.

now if you had implemented change-array-by-copy in engine262... :P