please add orEqual operator

[Caitlin Potter]

> I've had to track down vendor keywords to force C/C++ compilers to inline functions
> more than once, after the idiot thing's optimizers failed to do so, not even when I was
> using the inline keyword

Off topic, but remember that inlining isn’t always an optimization, and the compiler’s heuristics may actually be improving the performance of your build when it makes this choice! Of course they can still get it wrong, but..

It can be tricky for a method to do as good a job as a compiler could do, when optimizing this — for instance, a compiler may be able to eliminate redundant or unused tests entirely. A compiler can in some cases have static knowledge of the types of values it’s operating on, and save time accessing properties or invoking methods. A.p.includes will be O(n) in general, and there’s little the compiler can do to improve the algorithm. Beyond algorithmic improvements, you aren’t likely to see much optimization in the runtime function. But it probably doesn’t matter 99% of the time anyways, you probably aren’t going to rewrite a 1-liner into a huge switch statement or unreadable set of ternary expressions just to avoid that cost.

I’m quite sure someone will point out how wrong I am on any or all of the above points any moment now, I can’t wait =)

> On Aug 10, 2015, at 1:15 PM, joe <joeedh at gmail.com> wrote:
> 
> I actually like `[1, 2, 3, 4, 5, 6].contains(a)` better, too.  The question is, will engines actually optimize it.  I have to admit, I don't trust people who say VMs or compilers will do the optimizing for you.  I've had to track down vendor keywords to force C/C++ compilers to inline functions more than once, after the idiot thing's optimizers failed to do so, not even when I was using the inline keyword (which is an optimization hint, not an imperative).
> 
> I have never had this happen with only one compiler, either; if gcc won't inline a function, msvc won't either.
> 
> Instead of saying "the VMs probably will. . ." perhaps the TC39 committee should *mandate* that they do so formally, in the spec.  Then people like me could stop violating bits of the standard that aren't workable with how today's VMs work, like the return value of .next methods in iterators.
> 
> Joe
> 
> 
> On Mon, Aug 10, 2015 at 9:52 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com <mailto:andrea.giammarchi at gmail.com>> wrote:
> 
> 
> On Mon, Aug 10, 2015 at 5:42 PM, joe <joeedh at gmail.com <mailto:joeedh at gmail.com>> wrote:
> Isn't this what switch statements are for?  Perhaps a condensed operator version of a switch would be useful?
> 
>     if (a == 0 : 1 : 2) {
>     }
> 
> switch does eqeqeq comparison so is not exactly the same
> `switch(1) { case true: console.log('never'); }`
> 
>  
> 
> Or perhaps something similar to the set version, but without the set:
> 
>     if (a of 1, 2, 3, 4, 5, 6) {
>     }
> 
> 
> an `if/of` doesn't feel that right to me ... weird semantic
> 
> `[1, 2, 3, 4, 5, 6].contains(a)` looks better ?
> 
> 
>  
> 
> One could do this as a standard lib variadic function, I suppose:
> 
>     if (select(a, 1, 2, 3, 4, 5, 6)) {
>     }
> 
> 
> No, the main  point of having operators is that the engine could just skip the fallback part.
> 
> 
> `var a = 1 || doSomethingComplex(123)`
> 
> as example, will never execute doSomethingComplex whilc passing any value as argument should be already resolved as value.
> 
> 
> 
> In any case, FWIW, I think this is a classic "nostalgia operator" asked from someone that uses from another PL or just started using JS ... I wouldn't mind some well integrated and well thought shortcut, but I feel like this should be the least priority for ES.next
> 
> Best Regards
> 
> 
> 
>  
> 
> Cheers,
> Joe
> 
> On Mon, Aug 10, 2015 at 6:09 AM, <myemailum14 at gmail.com <mailto:myemailum14 at gmail.com>> wrote:
> Thanks I'll be searching through archive, and yea i think this is something very simple and yet innovative.
> 
> On Mon, Aug 10, 2015 at 3:55 AM, Peter van der Zee <ecma at qfox.nl <mailto:ecma at qfox.nl>> wrote:
> On Mon, Aug 10, 2015 at 3:50 AM,  <myemailum14 at gmail.com <mailto:myemailum14 at gmail.com>> wrote:
> > Isn't
> > prop ||= 0;
> > better than
> > prop = prop || 0;
> > and it can be even defined like this.
> > prop ||= var1 ||= var2 ||= 0;
> > but then i dont know how we can use it ike this
> > if (num == 3 ||=4 ||=6)
> 
> Sounds like you want two operators; `||=` for the compound assignment
> case and `||==` and `||===` for the "compare the RHS to the LHS of the
> last `===` or `==` op", or something like that. Defining a single op
> for both of these cases is likely to lead to ambiguity.
> 
> The `||=` (and `&&=`) case has been discussed a couple of times, look
> in the esdiscuss archives.
> I'm sure something like `||==` has been discussed too though I don't
> recall it myself. I tend to use switches myself for this in case perf
> is an issue.
> 
> - peter
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150810/5c99e0a0/attachment.html>