This returns undefined, and it鈥檚 two bytes shorter than void 0 (it鈥檚 also 5 bytes shorter than undefined). The . operator has a higher priority than the void operator, so it鈥檚 safe. A plugin could also replace all instances of void 0 in other code with 1..u.
Doesn't seem like a good idea since everything would break if someone did Object.prototype.u = 4. We _could_ hoist the definition with a var u = void 0; at the top of the file if there are more than a couple references to undefined though.
@loganfsmyth If you think it鈥檚 likely that someone is going to do that, then it could be changed to any other valid character. 1..碌 only takes up one more byte in UTF-8.
Right, but it still means your exposing your code to the potential for deliberate breakage that wouldn't be present otherwise.
A little brain-dump for @loganfsmyth's hoisting suggestion...
Remember that undefined is the default value for a variable, so this could be shorter at var u; or let u; (although I guess it would be more robust to use const u = void 0)
Also, there may be opportunities to piggy-back on a list of other variables declared, so could be as little as 2 additional characters. e.g. if a and b are already defined in a var a,b; declaration, then we only add ,u to get var a,b,u;
Or, if you want to use const for robustness, you place the const immediately after an uninitialised variable declaration: var a,b;const u=a;
Hah, good call about not needing =void 0; :P
One other thing I'll add, inserting a new variable is potentially iffy, we'll need to know whether the file being minified is a <script> or not, since that would potentially be creating a new global variable.
This is already brought up in https://github.com/babel/minify/issues/25#issuecomment-230671685 (last point).
Agree that adding new variables to toplevel isn't safe enough. But this requirement is something that has come up earlier - in minify-builtins, we solve it by inserting this new variable in certain parent scopes (function/block && NOT program) based on number of usages. The same thing can be done for void 0.
For example,
function foo(x, y, z) {
this.x = x === void 0 ? "x" : x;
this.y = y === void 0 ? "y" : y;
this.z = z === void 0 ? "z" : z;
}
function bar(x, y, z) {
this.x = x === void 0 ? "x" : x;
this.y = y === void 0 ? "y" : y;
this.z = z === void 0 ? "z" : z;
this.k = 2;
}
can be transformed to
function foo(x, y, z) {
let _void0;
// ...
}
function bar(x, y, z) {
let _void0;
// ...
}
instead of hoisting _void0 to program.
I'll close this as duplicate of #25 as it's easy to refer to that issue for new features as it is in a single place. Feel free to discuss here or comment to reopen if necessary.
Most helpful comment
Doesn't seem like a good idea since everything would break if someone did
Object.prototype.u = 4. We _could_ hoist the definition with avar u = void 0;at the top of the file if there are more than a couple references toundefinedthough.