TC39 Delegates
2024-02-12
plaintext logs
prev next
source on github
03:58
<Justin Ridgewell>
bakkot: It looks like the matrix log bot died?
03:59
<Justin Ridgewell>
Newest updates are from 2024-02-06, missing the plenary
03:59
<bakkot>
ugh, let me kick it
03:59
<bakkot>
it hangs sometimes and I haven't tracked down why
04:00
<bakkot>
and the monitoring I have only detects outright crashes
04:02
<bakkot>
Justin Ridgewell: ok, back up to date
15:36
<Mathieu Hofman>
On the topic of parameter decorators, I wonder if other people have looked through the examples in the readme of the proposal, and if so what their reactions are: https://github.com/tc39/proposal-class-method-parameter-decorators#ecmascript
My reaction is that I want it. We have a use case similar to the FFI marshalling & parameters validators. Sure you could put all that on a method / function decorator, but that'd require "redeclaring" the parameter list in the method / function decorator itself, risking getting out of sync with the actual parameters.
19:33
<littledan>
the thing is, you kinda could do this with extractors, but I agree it would be better to apply parameter decorators, semantically
19:34
<ljharb>
how, with extractors?
19:45
<littledan>
For validators, serializers, casts, etc, you can do function f(x(a), y(b)) { } instead of function f(@x a, @y b) { } just by having x and y have custom matchers. But IMO if it's not logically undoing what x and y do, it's not quite semantically appropriate.
19:45
<littledan>
note that this doesn't work for metadata
19:52
<rbuckton>
Some FFI marshaling scenarios require up-front knowledge of the function parameters incl. data types, string decoding behaviors, etc., that makes extractors a poor fit.