Jacob Bloom (2020-04-26T02:08:54.000Z)
mr.jacob.bloom at gmail.com (2020-04-26T02:21:42.938Z)
Is the Perl syntax opt-in like the proposed operator? Or does it happen on all accesses to nulls? If it's opt-in in JS, then it doesn't seem to me that it'd cause too much unexpected behavior, though it could be argued that it's ripe for abuse by new devs trying to avoid errors. Something that might be a more generalized middle ground (and could later assist in transpiling the !. operator) is a "getsert" (?) method in the standard library that takes a default value and sets it on the parent object if that property is currently unset: ```javascript Object.getsert = (obj, identifier, defaultvalue) => { if (!(identifier in obj)) obj[identifier] = defaultvalue; return obj[identifier]; } const table = {}; console.log('before getsert:', table.user); // undefined console.log('during getsert:', Object.getsert(table, 'user', 5)); // 5 console.log('after getsert:', table.user); // 5 ``` ...I have concerns about such a method's usability though, since a getsert is far more verbose than a normal get. It'd be more convenient on Object.prototype (e.g. `table.getsert('user', 5)` ), but I assume that's a no-go. Oh also, I think the proposed syntax would collide with TypeScript's non-null assertion operator https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html#non-null-assertion-operator -- I don't know to what degree that's a concern when proposing new JS syntax