If you care about performance, it's a bad idea to feed external input into a deterministic hash function. That invites attacks such as Hash Flooding: https://en.wikipedia.org/wiki/Collision_attack#Hash_flooding

If you care about performance, it's a bad idea to feed external input into a deterministic hash function. That invites attacks such as Hash Flooding: https://en.wikipedia.org/wiki/Collision_attack#Hash_flooding

Performance and/or security. This is one of the reasons why I indicated non-determinism for string hashing between application restarts is a good thing, actually.

The "bad thing" case (non-determinism being bad) seems so narrowly focused that I have a hard time believing it should apply broadly across the language.

Plus, AFAIK equals/hash is how every implementation implements maps natively, it's just not exposed to user code.

Ashley Claymore: I understood from this earlier assertion by Ron that implementations have already found ways to square the circle with respect to "different and never equal", but maybe I misunderstood?

The overhead incurred by a CompositeKey just seems like a non-starter to me. Maybe we could find another approach that can overcome these caveats. For example, a Hasher class instead of a global Object.hash(). A given Hasher could just use a monotonically increasing number for each unique object instance it comes across, and maybe is configurable as to how it handles string hashing (e.g., algorithm, randomness, seed values, etc.). Then your equaler looks like { equals(a, b), hash(obj, hasher) } and you then can write new Map([], { equaler, hasher }). Object hashes could be deterministic without being a global communications channel. String hashing can be deterministic if you want it to be, or not, as best fits your scenario.

it was not clear to me that this feedback applied to interning at construction time, with a constructor function rather than syntax

That is what is generally done to work around this currently, but it has drawbacks:

• It's not resilient to version conflicts when multiple versions of the same package are installed.
• If globally accessible, it must be randomized to avoid becoming a communications channel.
• It doesn't work across threads for something like shared structs.

It's also only part of the problem with hashing, the other problem is strings.

rbuckton: If your goal is to have a concurrent map, maybe we should focus on that. That could work both by identity (by default) and converting to a R&T for structural comparison (opt in with a keyBy function). Would that implement what you need?

I'm not sure what you mean by "this is what is done" -- the concurrent map construct doesn't exist yet

I was responding to nicolo. Also, a concurrent map does exist. I had to build one for TypeScript as part of experimenting with shared structs. The lack of an Object.hash() required a significant number of workarounds that I wouldn't want to rely on in a released product.

And yes, if concurrent collections were part of the MVP for shared structs then I might be less concerned, but I don't see that being likely.

• Implementations need to be able to choose more efficient string hashing algorithms as they become available, and thus requires non-determinism between upgrades.
• Strings are a notorious source for hash collisions, and thus requires non-determinism between app restarts.

I can understand your concern there but in this chat we've identified some serious concerns with exposing identity hashcodes... maybe it would work better to push on ConcurrentMap as a follow-on for shared structs, rather than these lower-level utilities in other parts of the language.

We already know that we must not expose a deterministic identity hashcode operation. But we also have serious issues around nondeterminism. I'm especially concerned with the interop risks over time. This all is why we're currently taking the middle path of hiding the identity hashcode.

I can understand your concern there but in this chat we've identified some serious concerns with exposing identity hashcodes... maybe it would work better to push on ConcurrentMap as a follow-on for shared structs, rather than these lower-level utilities in other parts of the language.

Getting shared structs through committee is going to be an uphill battle. Concurrent collections are a necessity to make them practically useful in large-scale applications. If the MVP for shared structs suddenly became stage 4 today I still wouldn't be able to use them for TypeScript without having to build my own concurrent Deque, Work stealing queue, ConcurrentMap, and ConcurrentBag/ConcurrentSet.

for example you could check whether the hashcode has changed as an indicator of whether your JS program has restarted, which feels off

"this is an uphill battle" doesn't necessarily imply that taking the battle somewhere else will make it easier

It's easy to imagine someone depending on string hashcodes having certain properties

shu: I hear you have concerns re: import defer and it's usability for the web. happy to talk about it

shu: Could you clarify whether "better" is good enough, when it comes to interning overhead?

I would volunteer for note taking, but I'm getting pinged on non-TC39 things a lot right now.

hard agree with USA here

stage 1 acknowledges that localisation is important for the web and something we should try to address within TC39; that remains the case, regardless of how long it will take or how hard it might be to provide a solution

It would beed a cover grammar, but using fn() is much better than using void = fn()

This just feels risky to me, maybe it's better to keep this in extractors and pattern matching and explicit resource management, even if it would be nice to have it elsewhere.

i don't understand how any existing variable name can be web compat

i don't understand how any existing variable name can be web compat

Instead of "redeclaring a variable is an error in strict mode" it becomes "reading a variable that has been redeclared in strict mode is an error"

but var _ = 1, _ = 2; is not illegal anywhere

Instead of "redeclaring a variable is an error in strict mode" it becomes "reading a variable that has been redeclared in strict mode is an error"

sloppy mode so popular though?

The error cases remain the same, with the difference that the error is moved from declaration position to reference position

i am still confused what the proposed semantics is for sloppy mode

it's on us for not doing modules/namespaces well at start I guess

How would that change things?
People do import _ from "lodash"

vars and function params can be redeclared, but if you redeclare a let/const then it throws when you reference the binding

nothing wrong with namespace imports

nothing wrong with namespace imports

okay well, i don't think this proposal meets the bar thus far for complicated binding handling

so closures which capture the old one still work

The closure would have to move the value in. I’m not sure it works the way you think.

Actually you can’t reference _ in a closure (I’ve never tried before): https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ab28412522dba608f6964c9a11ce600f

i do not believe that it accepting boxed primitives - and unboxing them, ftr - is going to encourage usage of it. i strongly believe the opposite

if you want to use pattern matching, with the current semantics, even if you do the very unlikely thing of making a boxed primitive, you will as rapidly as possible unbox it.

just like how sparse arrays are terribad, and all new stuff just papers over that by making them dense, and we do NOT throw when you have a sparse array, we shouldn't throw or fail when you have a boxed primitive. we should just paper over it and get you into "normal primitives" as fast as possible.

I thought V8 optimized array destructuring

I thought V8 optimized array destructuring

I remember they published an article about it several years ago

@rbuckton Why do we lose assignment patterns with _?

Do other engines think that throwing for each failed match seems like it would be way too slow?

Because you can already write [_, _] = ar today and it has a meaning.

Do other engines think that throwing for each failed match seems like it would be way too slow?

Do other engines think that throwing for each failed match seems like it would be way too slow?

We just need the ability to redeclare.

But that’s behaving exactly the way discard bindings should.

i mean in general i agree with george but i got bad news for him on the understandability of JS wrt user code today

I agree it's more of a discussion for pattern matching I don't want to get to a place where we have throwing here and have to have a totally different mechanism for pattern matching

If we're creating a brand new feature, why not aim higher? Especially if the increased power/flexibility is not required for the majority of use-cases

Redeclare what? if _ isn't already declared, [_, _] = ar will either throw in strict mode, or introduce a global in non-strict mode. I don't think we can change that. If you want to use _ as a discard in assignments, you do that by declaring a var _ somewhere in the same scope.

Oh, I was assuming _ was already a binding in scope. Why can’t we make sloppy mode continue to function as is, and just not create the binding in strict?

That would definitely be a violation of ljharb 's concerns. I think we can only use _ if it would otherwise be syntactically illegal. If you have

var _ = require("lodash");
function f() {
  [_, _] = [1, 2, 3];
}

Then you're breaking code non-locally.

Regarding the const InventoryID(customerId) = "Contoso-12345" example, I've regularly described extractors as unapplication (the Scala method is literally called unapply()). This dualilty is important for both data types and primitive types:

const InventoryID(customerID, Name) = InventoryID("12345", "Contoso");

I don't disagree that there are use-cases that would be addressed with this, just that the power required to support them (when these are the minority of use-cases, and other languages e.g. OCaml do fine without supporting this), allows completely arbitrary behavior which means that it will be more difficult to understand and analyze the main use-case, which is matching against some datatype and extracting values from it.

Do you mean something more like Python's __match_args__ approach? I've discussed that with the pattern matching champions and there was fairly strong opposition.

rbuckton: Are there any dynamically typed languages that support extractors?

I'm not familiar with that feature, but to explain what I mean in loose terms, you could still have a customMatcher-like function which can decide which values to return for extraction, but the check of "is this of this datatype" (be it instanceof or whatever) would always be run, separating these two concerns

my presentation is largely about refuting a past argument that he made

Random thought: Would @@customMatcher as a generator be potentially more performant than returning an array or iterator?

There is no opportunity to run user-defined code as part of that validation. It can also only read public properties, but that's fine for Python since it does not have privacy. A Point[Symbol.matchArgs] = ["#x", "#y"] in JS wouldn't be able to read a private #x in JS.

Is Mark Miller here this afternoon?

I guess this would be similar to how both Python and Dart use these features

Random thought: Would @@customMatcher as a generator be potentially more performant than returning an array or iterator?

eemeli: Yes, returning a single value would be significantly more performant

I understand the semantics you are describing. I just see no reason to introduce an artificial limitation.

It seems like languages like Dart, Python, OCaml, Rust all have this limitation. And the reason is what I described before, there is a trade-off between the flexibility this feature provides, and making code easy to understand (for both humans and tooling)

Yeah, given that there are trade-offs and different languages have made different design choices regarding this trade-off, it seems worth discussing at least!

Besides, writing an extractor to handle a non-datatype input is more complex than the default implementation for a data type. In the pattern matching proposal, class C {} will have a default [Symbol.customMatcher] that performs a brand check and returns the subject. You get it for free unless you want to do the more complex things.

ok so why is this stage 3 instead of a normative PR? the discussion was hard to follow

was this one even a proposal before today?

is this only useful for bundlers? if so, can't they start using a non-standard directive?

is this only useful for bundlers? if so, can't they start using a non-standard directive?

I kinda share danielrosenwasser 's composability concern

re semver: What if we standardized semver in Ecma? Darcy Clarke is interested in this, with a better specification than exists currently (including Node semver ecosystem reality). We could do it in a new TC in Ecma, or maybe a TC39 TG. Who's in? Eventually maybe it'd make sense for JavaScript to have a small built-in library for working with semver values, once we have the core defined (this is an extremely popular npm package).

imo we shouldn't have allowed static import of a module using TLA in the first place

re semver: What if we standardized semver in Ecma? Darcy Clarke is interested in this, with a better specification than exists currently (including Node semver ecosystem reality). We could do it in a new TC in Ecma, or maybe a TC39 TG. Who's in? Eventually maybe it'd make sense for JavaScript to have a small built-in library for working with semver values, once we have the core defined (this is an extremely popular npm package).

Can this be tested like:

import "./start-test.js";
import "./app.js";
import { wasThereATick } from "./end-test.js"; // shares state with start-test
assert(!wasThereATick);

how about

import { ticked } "./start-test.js";
import "./app.js";
assert(!ticked); // ticked live binding

this is like implementing lodash.throttle but you also need to be a ES module specialist

"be a real subclass" is the same as "has the expected slots and [[Prototype]]"

So if extractors or pattern matching would provide for an Error[Symbol.customMatcher] "regardless", does it make sense to advance a separate proposal on this?

Maybe this could be an npm library?

So if extractors or pattern matching would provide for an Error[Symbol.customMatcher] "regardless", does it make sense to advance a separate proposal on this?

yes, that's an excuse we can use to stash the check there -- Jordan has generally been requesting that proposal authors find a way to make such an API (though it has to serve some sort of dual use case today, due to this set of arguments we're having)

i mean that i'm 100% fine with domexceptions passing this predicate, or not. what would you prefer?

i do

yes, that's an excuse we can use to stash the check there -- Jordan has generally been requesting that proposal authors find a way to make such an API (though it has to serve some sort of dual use case today, due to this set of arguments we're having)

then no, DOMException does not inherit Error and missing some property Error have

@littledan regarding "What policies has TC39 adopted?" do you think we need to cover this during Jordan's limited time?

yeah, DOMException is strange, domException instanceof Error is true, but they do not have all properties of Error (eg. no stack?)