If we had an operator for getOwnProperty(), lookups could be optimized. No need to traverse the prototype chain.
Is it worth it?
if( a..x ) { /*...*/ }
//equivalent:
if( a.hasOwnProperty( 'x' ) && a.x ) { /* ... */ }
Edit:
The operator would behave like a call to this:
Object.prototype.getOwnProperty =
function( property ) {
return this.hasOwnProperty( property ) ? this[ property ] : undefined;
}
(I seriously thought this function existed until a few seconds ago...)
Lookups already are optimised so that they don't traverse the prototype chain every time.
Huh. Sounds impossible, since there's no way to tell whether the chain has changed without checking.
But, meh. Not sure how much of a gain that would have been anyway.
That looks like the dart cascade syntax:
object
..peoperty1 = "some value"
..method1(10, 100)
..property2 = false
maybe there's such a proposal in js?
I don't know. It could also be a.:x, or anything really.
My question is whether or not it would be worthwhile, the same way const helps optimize.
In what way does const help optimize? It's for readability and declaring intent, not optimizability.
The technique is called ‘Inline Caches’. There are a few posts about it such as this one: Explaining JavaScript VMs in JavaScript - Inline Caches
@ljharb const encourages programmers to write optimizable code. Same as "don't use eval" and "don't use with" to stay in strict mode.
@aclaymore Thanks for the link. Very interesting read.
That article seems to be entirely about object properties.
I agree that not reassigning a variable can help optimizations; I’m reasonably sure that you don’t need to use const for that tho. I love const, so I’d love to be wrong.
Yes, I think for optimization, "not reassigning" is identical to using const. I hope that when programmers have to decide between let, var, and const, they will be more attracted to code that only uses variable reassignment when it is actually necessary. I think that code, on average, would optimize to something faster.
However, unnecessary reassignment might be compiled into expressions anyway. I don't really know. Maybe someday I will have time to read V8's source.
I wasn’t clear. The link was in response to an earlier message about optimising property lookup, rather than about const 
I love const, so I’d love to be wrong.
feel free to mark this off-topic, but i'm not a fan of const. like predicting the shape of classes, web-devs like me are terrible at predicting whether a variable should be constant or mutable when fleshing out whatever ux-driven-feature we're hired to do.
const creates needless code-churn/tech-debt when i frequently need to "re-mutify" things during ux-code-rewrites, when i should've just used var or let for everything from the start.
Well, I 100% agree on "predicting the shape of classes". I think it's impossible.
And I love const, but this thing...
I haven't encountered the problem you're describing, but I do tend to cause bugs by typing const without thinking. (I use mostly functional programming, and const is just a natural fit when everything is immutable anyway.)
After this thread and looking into JS optimization a little, I would recommend not using const unless you feel it is improving your code and development process. (If your linter requires it, you have my sympathies!)
As far as optimizations go in general, I think this is on-topic. Optimizations should be offered to developers, not forced on us. But what the spec offers, employers might require. Changes might not be as optional as they seem.
Also, I think we've established that property lookups do not need to be optimized via a dedicated operator, so this thread's question is resolved.
What you're looking for already effectively exists as a stage 1 proposal: GitHub - tc39/proposal-Declarations-in-Conditionals
I think you linked the wrong proposal.
No, it's the right proposal. Why I said "effectively" - it does what you want, just it wasn't the primary purpose of it.