The only use that came to mind was detecting a property descriptor in a
prototype chain. Sure is not a day to day use case, but it's useful when
writing libraries that involve descriptor modifications (decorators, for
example, will largely involve it). Recently I had to get the descriptor of
properties in a potencial deep inheritance (current Object helpers only
return own descriptors), and used the `in` operator to guard the prototype
recursive search.

``` js
const searchRecursivelyPropDescriptor = (obj, prop) =>
  !obj
    ? undefined
    : Object.getOwnPropertyDescriptor(obj, prop) ||
searchRecursivelyPropDescriptor(Object.getPrototypeOf(obj), prop);

const getPropertyDescriptor = (obj, prop) =>
  prop in obj ? searchRecursivelyPropDescriptor(obj, prop) : undefined;
```

Anyways, we can't simply ignore the operator, if we are getting a
`!instance` and opening precedence to future operators (`!on` or `!hasOwn`)
I don't see any problems with a `!in`. Legacy bad design should not affect
language consistency of new features.

Em qui, 19 de jul de 2018 às 12:07, Mike Samuel <mikesamuel at gmail.com>
escreveu:

> On Thu, Jul 19, 2018 at 10:40 AM Augusto Moura <augusto.borgesm at gmail.com>
> wrote:
>
>> Of couse the usage of `in` is most of the time is not recommended, but it
>> has it place.
>>
>
> What places does it have?
> I remain unconvinced that `in` has significant enough use cases to warrant
> high-level ergonomics
> were it being proposed today.
>
> It exists, and it'll probably never be removed from the language, but I
> don't think it should be taught
> as a good part of the language, and linters should probably flag it.
>
> --
Augusto Moura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180720/b620eecb/attachment.html>

The only use that came to mind was detecting a property descriptor in a
prototype chain. Sure is not a day to day use case, but it's useful when
writing libraries that involve descriptor modifications (decorators, for
example, will largely involve it). Recently I had to get the descriptor of
properties in a potencial deep inheritance (current Object helpers only
return own descriptors), and used the `in` operator to guard the prototype
recursive search.

``` js
const searchRecursivelyPropDescriptor = (obj, prop) =>
  !obj
    ? undefined
    : Object.getOwnPropertyDescriptor(obj, prop) ||
searchRecursivelyPropDescriptor(Object.getPrototypeOf(obj), prop);

const getPropertyDescriptor = (obj, prop) =>
  prop in obj ? searchRecursivelyPropDescriptor(obj, prop) : undefined;
```

Anyways, we can't simply ignore the operator, if we are getting a
`!instance` and opening precedence to future operators (`!on` or `!hasOwn`)
I don't see any problems with a `!in`. Legacy bad design should not affect
language consistency of new features.