Small Proposal "!in"

[Mike Samuel]

On Wed, Jul 18, 2018 at 12:21 PM Michael Theriot <
michael.lee.theriot at gmail.com> wrote:

> I think it is irrelevant; the operator already exists and I would assume
> if you want the negation of it you are using it correctly in the first
> place. Otherwise are you not just arguing for its removal altogether? But
> to answer your question one case that comes to mind is trapping get/has in
> a proxy handler.


Why should we assume that only people who consistently use `in` correctly
would want the negation?  It seems that people who use it incorrectly
because they are confused about the precise semantics or don't care might
want the negation too.  If there are more of the latter then we should not
assume what you assume.

Proxy handler code is important, but very few developers will ever write a
proxy handler over their careers, so this seems like a marginal use case.
Besides, Reflect.has is probably a better choice in a proxy handler.

I am not arguing for removing `in`.  That would break the web.  I am just
arguing for prioritizing changes that provide features that more closely
match the semantics developers typically want over making it more
convenient to write code that seems to work in casual testing but has
subtly wrong semantics.







> On Wednesday, July 18, 2018, Mike Samuel <mikesamuel at gmail.com> wrote:
>
>>
>>
>> On Wed, Jul 18, 2018 at 11:05 AM Michael Theriot <
>> michael.lee.theriot at gmail.com> wrote:
>>
>>> I think `in` and `instanceof` could both benefit from having negated
>>> versions.
>>>
>>> Assuming the developer is using `in` correctly, hasOwnProperty concerns
>>> are irrelevant. Either way they would attempt to use !(a in b), not
>>> !hasOwnProperty.
>>>
>>
>> Why should we assume the developer is using `in` correctly?
>> Apologies if I buried my question at the end.  It was, what are the use
>> cases for `in` that would not be better served by an ergonomic, infix
>> hasOwnProperty?
>>
>>
>> Same reason we don't use...
>>> !(a == b) // a != b
>>> !(a === b) // a !== b
>>>
>>
>>
>>> !(a > b) // a <= b
>>> (!(a > b) && !(a == b)) // a < b
>>>
>>
>> I'm not sure this is relevant to your larger point, and I've already
>> conceded ergonomics, but
>> these last two are not equivalent because NaN is weird.
>>
>> a = NaN, b = 0
>> [!(a > b), a <= b]  // [true, false]
>> [!(a > b) && !(a == b), a < b]  // [true, false]
>>
>>
>>
>>
>>
>>> On Thursday, June 28, 2018, Tobias Buschor <tobias.buschor at shwups.ch>
>>> wrote:
>>>
>>>> I dont like to write:
>>>> if ( !('x' in obj) &&  !('y' in obj) ) {
>>>>      doit()
>>>> }
>>>>
>>>> I was even tempted to write it that way:
>>>> if ('x' in obj  ||  'y' in obj) { } else {
>>>>      doit()
>>>> }
>>>>
>>>> What about a !in operator to write it like this?
>>>> if ('x' !in obj  &&  'y' !in obj) {
>>>>      doit()
>>>> }
>>>>
>>>> _______________________________________________
>>> 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/20180718/08d09eeb/attachment.html>