Description
Suggestion
🔍 Search Terms
liveBinding Object defineProperty allocation export live view
✅ Viability Checklist
My suggestion meets these guidelines:
- [ x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [ x] This wouldn't change the runtime behavior of existing JavaScript code
- [ x] This could be implemented without emitting different JS based on the types of the expressions
- [ x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [x ] This feature would agree with the rest of TypeScript's Design Goals.
⭐ Suggestion
opt out of liveBinding added in #35967 for const values
📃 Motivating Example
Doing some profiling of an app I'm creating and seeing a lot of calls to the get function of Object defineProperty that was added as part of #35967. These might be optimized away when not using --trace-allocation-stack-interval but it would be great to not have to rely on the optimizer to do the right thing here.
I originally wanted to add a flag that would make sure that
doesn't unconditionally pass true here, but that would be a breaking change to existing Typescript code if the flag was used with a modifiable export (does the breaking change guideline count if someone needs to explicitly flag themselves into a behavior?)If the exported value is const then you don't need a "live view" of it. But it's not clear if there is a good way to communicate const-ness at the time the export expression is created.
💻 Use Cases
I think I can work around this by saving the value of the re-export to a variable local to the the current script/module and using that. But that seems cumbersome.