# Pastebin BDNJ1jk7
so, one-by-one, why it has to be built-in:
- Auto-bind: Well, this doesn't really *have* to be built-in, but I bet the optimization would be easier to implement that way
- Resource usage: If it's not built-in, we would need TCP-following functions to represent the block; implementers recently repeated their balk at such things
- Module import variants: Runtime is too late; all the imports have to happen before any code executes
- Tail calls: Maybe this is like auto-bind, but I think it would be much harder to avoid a performance regression if this is dynamic
- Class variants: This depends. Maybe these could be decorators, but we might need some more decorators features
- Function.prototype.toString censorship: I forgot the details, but when this was presented at TC39, some committee members were convinced it needs to be static
- Operator overloading declarations: If it's static, this helps code generation, since you know that no operators are overloaded when the declaration is missing
- Custom code transforms: It'd be unsound to base this off of a dynamic variable name, but maybe that would work in practice