<Justin Ridgewell> Does take() close immediately, or during the next .next() (that returns { done: true })

Alternatively, Symbol.geti/Symbol.seti and WeakMap:

WeakMap.prototype[Symbol.geti] = function(key) { return this.get(key); };
WeakMap.prototype[Symbol.seti] = function(key, value) { this.set(key, value); };

const privateDecl = new WeakMap();
obj[privateDecl] = 1; // -> privateDecl[Symbol.seti](obj, 1);
obj[privateDecl]; // -> privateDecl[Symbol.geti](obj);

This is potentially an example of how a decorator could accomplish the same thing as new syntax:

@spreadClass(Foo)
class Bar { }

Not that I'm opposed to the syntax, per se, but decorators would allow for experimentation with this idea in userland before adoption as syntax.

How to specify Symbol.iterator methods in classes?

For example, like what we can do with array literals,

var obj = {
  *[Symbol.iterator]() {
    yield 1;
    yield 2;
  }
};
var arr = [...obj];
arr.join(',')

one possibility that lightly encourages symbols but permits strings:

protocol X {
  x() { return 'symbol method'; }
  'x'() { return 'string method'; }
}

In C#, an interface is by default implemented implicitly:

interface Stringable {
  string ToString();
}
class Foo : Stringable {
  string ToString() { ... }
}

But can be implemented explicitly:

class Foo : Stringable {
  string Stringable.ToString() { ... }
}

Whether something is implemented implicitly or explicitly is purely up to the consumer of the interface

Maybe the discussion is a little bit too much into what is a "public API" and what not, the question is, whether the Introspection proposal has its usages or not. I think this is the question to answer:

"Is it worthwhile to let users introspect public fields" , regardless whether they are "public API" or not.

constructor(x, y, z) {
  if (z) {
    this.x = x;
    this.y = y;
    this.z = z;
 } else {
    this.y = y;
    this.x = x;
 }
}

this is terrible for performance and happens everywhere

Do protocols support inheritance? like

protocol P1 { ... }
protocol P2 extends P1 { ... }

And what happens if you do this:

protocol P1 {
  foo() { ... }
}
class C1 {
  implements P1;
  [P1.foo]() { ... }
}
class C2 extends C1 {
  implements P1;
}

I actually don't know if it's that much of a pain?

if (let x = someResource; ...) {
  using _x = x; // ensure dispose
}
else {
  // ...
}

let data = "outer";
if (true) {
  let data = 'if';
}

will definitely error on https://eslint.org/docs/latest/rules/no-shadow, which all the popular configs have enabled

ok so how am I supposed to write this in that case?

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

Example of else visibility in C#:

int[] ar = [1, 2];

if (ar is [var x, var y]) {
  Console.WriteLine(x); // ok
} else {
  Console.WriteLine(x); // static error
}

// vs


if (ar is not [var x, var y]) {
  Console.WriteLine(x); // static error
} else {
  Console.WriteLine(x); // ok
}

IMO, these are certainly not gross:

if (opt is Option.Some(let x)) {
  ...
}

while (iter.next() is { let value, done: false }) {
  ...
}

if (opt is Option.Some(let x)) {
  ...
}

if we're going to let you write

let Some(x) = opt

then I want to write the above as

if (let Some(x) = opt) {
  // ...
}

not your pattern matching thing

but seriously I would at least prefer that to the state where you can't write else at all.

I do think it would be a very strange inconsistency, though, and would much prefer it to be an error for the other kinds of declaration as well.