TC39 Delegates - Public Room Timeline

	TC39 Delegates	222 Members
	Feb meeting: https://github.com/tc39/Reflector/issues/516 Public logs at https://matrixlogs.bakkot.com/	9 Servers

Load older messages

Sender	Message	Time
18 Apr 2024
Michael Ficarra	I think some people may be opposed to it being on `Reflect`, but it seems so nice to have `call` sitting next to `apply` there	18:58:07
Richard Gibson	I don't know why the current dislike of receiver is so prevalent (cf. proposal-async-context#80 and the aforementioned proposal-promise-try#15) and assumed to be permanent, but I very much dislike the corresponding fracturing of the language in which new proposals gratuitously diverge from Function.prototype.{apply,call} and Reflect.apply—especially when discussion in plenary has raised opposition to anything that encourages more use of things like `.bind` and arrow wrappers.	18:58:09
Michael Ficarra	Richard Gibson: maybe because most of the time you don't need to specify receiver, and when you do, you have call-bound call to bail you out?	18:59:21
bakkot	`Function.prototype.apply/call` and `Reflect.apply` are special helpers, which are very rarely sensible precedent to use for other methods	18:59:22
	ljharbchanged room power levels.	18:59:41
bakkot	I am happy to have a `Function.prototype.tryCall` sitting next to `Function.prototype.try` for that use case, but I don't want to make the signature of methods like that worse for the common case of no receiver just for parity with `Function.prototype.call`	19:00:33
ljharb	the receiver argument in array methods is terrible and if not for precedent, i'd hope none of the new methods would have had it. bind, or an arrow, is The Way	19:00:51
ljharb	In reply to @bakkot:matrix.org I am happy to have a `Function.prototype.tryCall` sitting next to `Function.prototype.try` for that use case, but I don't want to make the signature of methods like that worse for the common case of no receiver just for parity with `Function.prototype.call` which is also why "receiver" and "varargs" is a problem, because having to put `null` when you don't care about the receiver sucks	19:01:17
ljharb	so, we should just omit the receiver	19:01:22
ljharb	* so, we should just omit the receiver. the language has lots of tools to handle that, and there's proposals for the ones it doesn't.	19:01:38
Richard Gibson	bind, or an arrow, is The Way have you forgotten that implementers specifically objected to proposals that would encourage their use? most of the time you don't need to specify receiver worse for the common case of no receiver Emphasis mine. This is presumptive about future language use, but even so I would agree if not for precedent in the existing ways to call functions with arbitrary arguments. To have new signatures leave no room for an argument that is present in all old ones seems like unnecessary complexity. If you want to break with the past and foster arrow functions, then make that be necessary for arguments as well (e.g., `try(() => fn(…))`).	19:08:58
bakkot	To have new signatures specifically require the user to think about receivers is unnecessary complexity	19:09:43
ljharb	In reply to @gibson042:matrix.org bind, or an arrow, is The Way have you forgotten that implementers specifically objected to proposals that would encourage their use? most of the time you don't need to specify receiver worse for the common case of no receiver Emphasis mine. This is presumptive about future language use, but even so I would agree if not for precedent in the existing ways to call functions with arbitrary arguments. To have new signatures leave no room for an argument that is present in all old ones seems like unnecessary complexity. If you want to break with the past and foster arrow functions, then make that be necessary for arguments as well (e.g., `try(() => fn(…))`). that wasn't about encouraging their use, but their overuse	19:12:48
ljharb	as for "make it necessary for arguments as well", i agree with that, which is why Promise.try didn't initially have that capacity, but folks wanted it so i added it	19:13:28
bakkot	I am happy to have additional methods which allow specifying the receiver, but now that we have spread args there's no reason to use `Function.prototype.call/apply` except when specifying the receiver - specifying the receiver is what they're for. It really, really does not make sense to consider them precedent for other functions	19:13:35
ljharb	either way, "no recevier, with arguments" is way way more common than "with a receiver"	19:13:44
ljharb	* either way, "no receiver, with arguments" is way way more common than "with a receiver"	19:13:58
ljharb	* either way, "no receiver, with arguments" is way way more common than "with a receiver", at least for any usage that isn't literally `obj.method(...args)`	19:14:16
Richard Gibson	In reply to @ljharb:matrix.org either way, "no receiver, with arguments" is way way more common than "with a receiver", at least for any usage that isn't literally `obj.method(...args)` by "more common" you're referring to authored code, right?	19:14:28
ljharb	yes? if the alternative is "generated code", we should not care about what generated code does	19:14:55
ljharb	* yes? if the alternative is "generated code", we should not care about what generated code does (wrt API design, only wrt breakage)	19:15:03
ljharb	* yes? if the alternative is "generated code", we should not care about what generated code does (not wrt API design, only wrt breakage)	19:15:09
ljharb	* yes? if the alternative is "generated code", we should not care about what generated code does (not wrt API design, i mean, only wrt breakage)	19:15:41
bakkot	It is worth caring about generated code, but that should take the form of supplying APIs suitable for generated code, not changing the APIs for human-authored code	19:18:26
bakkot	... human or llm I guess	19:18:31
Andreu Botella	In reply to @bakkot:matrix.org To have new signatures specifically require the user to think about receivers is unnecessary complexity +1 to this, especially because of language learnability. `this`/receivers aren't things that come early when learning JS, especially because of how they differ from the equivalents in other languages. Even if `Promise.try` and `AsyncContext` are advanced use cases, language learning is non-linear.	19:18:47
Richard Gibson	fine, I yield	19:20:14
Justin Ridgewell	I also think an inline syntactic arrow fn doesn’t have the same performance penalties that dynamic closure-returning helpers and `fn.bind()` would have.	19:31:35
littledan	Richard Gibson: have you forgotten that implementers specifically objected to proposals that would encourage their use? Thinking about "how many closures is this going to imply are allocated in real use cases" is different from "thisArg should be a thing". Signals try to pass the right `this` value to achieve a similar goal.	19:40:47
Michael Ficarra	* I often save this "call-bound call" (`Function.prototype.call.bind(Function.prototype.call)`) and use it throughout my programs	21:28:25

There are no newer messages yet.

Back to Room ListRoom Version: 6