please add orEqual operator

[joe]

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> wrote:

>
>
> On Mon, Aug 10, 2015 at 5:42 PM, joe <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> 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> wrote:
>>>
>>>> On Mon, Aug 10, 2015 at 3:50 AM,  <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
>>> 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/2c22f5f9/attachment-0001.html>