Historically, YAML libraries' approach to parse-immutable-ish concerns has been to define something like JSON.parseSafe and ask everyone to use that instead of JSON.parse.

I don't think this is necessarily a good idea, but it's the closest historical precedent to the proposed change.

https://webidl.spec.whatwg.org/#js-DOMException-specialness

In the JavaScript binding, the interface prototype object for DOMException has its [[Prototype]] internal slot set to the intrinsic object %Error.prototype%, as defined in the create an interface prototype object abstract operation. It also has [[ErrorData]] and [[Stack]] slots, like all built-in exceptions.

Additionally, if an implementation gives native Error objects other special powers or nonstandard properties (such as line and column properties), it should also expose those on DOMException objects.

Olivier Flückiger:

if (using resource = getResource(); resource.needsUpdate) {
  resource.update();
} else {
  await postMessage('no updates required');
}

For comparison, a way to write this if the variable was visible in else would be:

let goToElse = false;
{
  using resource = getResource();
  if (resource.needsUpdate) {
    // ...
  } else {
    goToElse = true;
  }
}
if (goToElse) {
  await postMessage('no updates required');
}

fwiw I strongly want to use this syntax for extractors as well:

if (let Some(x) = val) {
  // only runs if the extractor succeeded
} else {
  // only runs if the extractor failed 
}

I think that's a natural extension

Ron really doesn't like this because he thinks it is not general enough for pattern matching, which I think inclines me against pattern matching rather than against this proposal

Just so I understand, we're debating whether this will be TDZ or a reference error? Because I think it is perfectly meaningful from the author side and I can see use cases for it. Could it be a mistake? Sure. But so could many other things. That's why we have linters.

``js
let data = whatever();
if (let data = foo()) { ... }
else { console.log(data); }

IMO making this an error or TDZ is completely baffling and inconsistent with how scoping works anywhere else. TDZ implies uninitialized but same scope. This is _not_ the same scope.

pattern matching gives you precised control over if a property should be matched or should be a declaration, so it may look like

if (val is Some({ match: { x: Some(1) }, let binding })) {}

I agree, but it's no more or less confusing than

let foo = 1;
{
  let foo = 2;
}
{
  console.log(foo); // logs 1
}

which works just fine today.

I don't think any user is really expecting this tranpsilation:

// In
if (using x = foo) {
  console.log(x);
} else {
  console.log('else')
}

// Out
outer: {
  {
    let x = foo;
    if (x) {
      console.log(x);
      break outer;
    }
  }
  console.log('else')
}

I mean test and create new binding

if (let decl = expr())
if (expr() is let decl)

for this simple case I think it maybe ok because decl in if is better in this case
but if decl in cond supports destruction it will overlap more

if (let { x, y } = point(); x === 0)
if (point() is { x: 0, let y })

then the committee may think it's a big overlap and require pm to match inside the let { ... }

for (var x;…) ((x) => { setTimeout(() => x) })(x);

We teach closure capturing as an interview gotcha question

right. it's a gotcha precisely because the transpilation is unexpected.

also, that suggests that you wouldn't be able to do an early return, so if you do think in terms of transpilation and that's your mental model you will still be confused. but in practice it is fine because, again, people do not think in terms of transpilation

How would you break inside any closure?

people do not think in terms of transpilation

I think everyone does.

I think everyone does.

This is exactly why we're not representative users 😂

for (let x = 0; x < 3; ++x) {
    x = ((x) => (setTimeout(() => x++), x))(x);
    if (condition()) break;
    x = ((x) => (setTimeout(() => x++), x))(x);
}

Or if we really want:

for (var x = 0; x < 3; ++x) {
    let y = x;
    setTimeout(() => y++));
    if (condition()) break;
    setTimeout(() => y++);
    x = y;
}

Re: developer expectations, for anyone interested I just posted:

• Bluesky post
• Twitter poll
• Mastodon poll
• https://github.com/LeaVerou/blog/discussions/139

Still too early to draw conclusions (and polling on social media has its own, separate, biases obvs), but could be interesting as another data point.

current pattern matching does not create bindings by default, some examples:

x is { let a, b: 1 }, test x.b === 1 && "a" in x and create binding a
x is { a }, test "a" in x and no binding created.
x is { a: Some(let val) and let a }, test "a" in x && Some[@@matcher](x.a) and create binding a (equal to x.a) and val (equal to Some[@@matcher](x.a).next().value)

let a = "other";
if (let a = false) {
  log(a);
} else {
  log(a);
}

if (let name = ...; name.length > 0) {
  log(name);
} else {
  log(name);
}

I like using var for things like

try {
  var foo = something():
} catch (e) {
  return;
}

use(foo)

I wish I were in a better position to discuss pattern matching, but all I have with me is my phone at the moment (and this takes awhile to type out). I looked into various ways to adopt pattern about 4 years ago now after researching the approaches taken in Rust, Swift, Python, C#, and a few other languahes, and was initially optimistic about the possibility of if..let. I found, though, that our current semantics for binding and assignment patterns are incompatible with well established pattern matching tenants. Our destructuring patterns aren't nearly strict enough, which would mean either inconsistent semantics between a normal let and if..let, or the need to introduce new syntax to opt-in to stricter matching behavior. The other big concern was how to differentiate between a binding and a reference. Typed languages can leverage static analysis and type systems, but JS does not have that capability. This, in turn, meant even more syntactic complexity to work around that results in footguns because it would by necessity be opt-in and not opt-out. The end result would either be confusing semantics or messy syntax, or a very limited, rough and inconsistent pattern matching experience.

I found, though, that the C# syntax and semantics were a good fit. C# separates destructuring (called "Deconstruction") from pattern matching and has both a branching match expression form and an infix is expression form. It's syntax for named bindings is both simple and explcit: Pattern Identifier?, where Pattern includes type names as well as var. Adapted to JS, this would mean you could write something like:

if (val is [Number x, Number y])...

or

if (val is { a: { b: String } a })...

or just

if (val is { a: let a })...

to both match and extract deeply nested values without bind/reference syntax confusion, while avoiding extra syntax for the most common cases (testing against types). I find patterns like x is Map or Set, x is not String, x is Some(Number), and x is [Number, Number] extremely convenient and clear, while x is @String or @Number (or similar) far less so.

I don't understand the question.

.buffer is basically:

function buffer(iterator, N) {
  let buffer = [];

  for (let i = 0; i < N; i++) {
    buffer.push(iterator.next());
  }

  return {
    next() {
      buffer.push(iterator.next());
      return buffer.shift();
    },
  };
}

Ashley Claymore: my topic was, IIUC you were concerned that people would write { a: 0, b: possiblyUndefined } and { a: 0 } and expect them to be equal. currently it is annoying to omit the property in the first case, and it's clunky to explicitly add a b: undefined in the second case, so I get that.

would you feel differently if we had syntax where they could write { a: 0, b?: possiblyUndefined } where the property would not be created if the value was undefined? that way you could easily omit the property in the first case.

A case like

let obj = { a: 0, b: undefined };
let comp = new Composite(obj);
'b' in obj; // true! 
'b' in comp; // false! (because undefined was omitted)

Is likely to be a bit confusing for users... likely an edge case but still ... Is the proposal still planning to expose the members of composite as properties on the composite?

sorry, still stuck on the undefined bit here... one example case where ignoring undefined causes.. weirdness

const err1 = new Error('A', { cause: undefined });
const err2 = new Error('A', { });
const comp1 = new Composite(err1);
const comp2 = new Composite(err2);
comp1 === comp2;

These are definitively two separate sources, but they end up resulting in the same Composite? That feels... off. When we're talking about options bags / object literals that are passed in, it seems ok, but for stuff like this... treating them as equivalent feels ... wrong

or, say you want to fetch a bunch of files, but the files have associated filenames, like [{ name, url }, { name, url }]; you ultimately want a Map from name to url and you know by construction that the names are unique. so you do

let result = new Map;
let iter = items.toAsync()
  .map(async ({ name, url }) => [name, await fetch(url)])
  .buffered(3); // 3 fetches at once
for await (let [name, file] of iter) {
  result[name] = file
}

here's an example of exactly that pattern, which I think of as a work pool: https://gist.github.com/gibson042/d8ab425d133400959bc5bb875898a97b#file-github-fixer-user-js-L1023-L1029

concurrency ramps up to the specified capacity as quickly as possible by take()ing input iteration results from source, output iteration results are yielded as quickly as possible (as [index, result] pairs in case the consumer wants to restore ordering), and new inputs are take()n immediately thereafter until source is exhausted