Darien Maillet Valentine

@ljharb I’m not sure I understand. The revision still says: > If func is a Bound Function exotic object or a built-in Function object, then return an implementation-dependent String source...

Oh, derp, you were responding to the first part of what I asked rather than the last part I was thinking about, naturally :)

It’s intended for specialized use cases. It would impact traces in tools like Bugsnag and Sentry. If used correctly, it could improve them; it would reduce noise from internals. The...

@misterdjules Yep, I agree — that’s why I suggested an (admittedly under-researched) alternative where redaction requires express ‘blessing’. Only the author can potentially distinguish _here, we anticipate a possible error...

@BridgeAR The visibility of the full stack in REPL or other tooling is not mandated by this proposal, fwiw. Only the error.stack property. That is, this is about what’s introspectable...

> A related question: should we allow @super()? Probably not unless there’s a definite use case? It could be done with parentheses regardless and if really doing this, parentheses would...

@ljharb If I understood it correctly, @JLHwung’s example intended the parentheses to be those of `SuperCall`, not those of the existing decorator grammar — i.e. `@@(super())` with its outer parens...

> Expanding DecoratorCallExpression benefits JS minimizer, those have readability concerns can always disable such patterns via linter rules. If a minifier can remove two bytes from an expression that nobody’s...

Is the possibility of it being intermediate substantially higher than the possibility of it being written directly? Wouldn’t you still need to be authoring decorators as classes which use return...

always bet on JS, @ljharb