00:13
<jschoi>
* I’m confused. Everything I just said was trying to explain how the pipe operator would incentivize using more plain functions and less prototype methods, by at least some amount.
00:21
<jschoi>
…Whoops, I just had to delete a confused comment I had made a minute ago. Matrix Element just displayed a message from Sunday to me right below my previous response, which made me think that we were going in circles. Turns out a Matrix or Element bug was just displaying the messages in this thread out of order temporarily…
00:56
<Richard Gibson>
to be honest, I was only thinking about a consumption-oriented bundle, but you're right. I think this detail will hinder export-side adoption, because it's basically asking library authors to abandon lots of ergonomic conveniences (extends, private elements, etc.)
02:50
<Ashley Claymore>
Something like https://github.com/tc39/proposal-private-declarations will likely be needed to help on the producer side 
02:51
<Ashley Claymore>
extends is maybe less of an issue as pipeline already means the consumer is bypassing any dynamic dispatch 
03:15
<Richard Gibson>
but it still means manually propagating methods associated with the parent
04:16
<Ashley Claymore>
to achieve reliable DCE the connection between declaration and usage needs to be static.
is there an alternative?
14:22
<Richard Gibson>

extends doesn't disrupt such connections, nor even the ability to observe them. This is in part about the gap between code that static analysis can classify as unused vs. code that current static analysis does classify as unused, and also about interplay between authors, tools, and the language itself. As a demonstration, consider expanding the example from above:

export class C {
  /* constructor and "core" members */
  #counter = 0n;
  constructor(initial = 0n) { this.#counter = BigInt(initial); }
  adjustBy(n) { this.#counter += BigInt(n); }
  get counter() { return this.#counter; }
};
const { prototype: CShakable } = class extends C {
  /* tree-shakable methods */
  increment() { this.adjustBy(1n); return this.counter; }
  decrement() { this.adjustBy(-1n); return this.counter; }
};
export const { increment, decrement } = CShakable;
import { C, increment } from "c.js";
console.log(increment.call(new C(99n))); // 100n
16:14
<Ashley Claymore>
This is similar to CJS. Some CJS patterns were statically analysable - and in some tools more than others. ESM syntax was great for giving tools a standard to follow.
16:16
<Ashley Claymore>
the above could be re-written in so many different ways
16:17
<Ashley Claymore>
export const { prototype: { increment, decrement } } = class ...
16:18
<Ashley Claymore>

or

class Methods extends C { ... }
export const { increment, decrement } = Methods.prototype;
16:59
<Evan Winslow>

My first outreach attempt (Three.js): https://discourse.threejs.org/t/im-on-tc39-would-three-js-be-interested-in-tree-shakable-methods-syntax/90519

My takeaways:

  1. Don't reply more than once per week
  2. Ignore replies that consist of off-topic ratholes and feelings
  3. Tweak OP to address common questions/misunderstandings

Feel free to judge my attempt mercilessly so I can do better next time. Thx :)

17:06
<Ashley Claymore>
this is really good
17:07
<Ashley Claymore>
definitely some mis-information from others in there. But that's always the way on the internet.