FW: Re: Strict Relational Operators

[Matthew Robb]

Also there was once the is/isnt operators and they lasted in ES6 for a very
long time and went pulled for reasons like this.

On Apr 15, 2017 4:06 AM, "Isiah Meadows" <isiahmeadows at gmail.com> wrote:

> Okay, I stand corrected... (I forgot about those)
>
> On Sat, Apr 15, 2017, 04:01 Jordan Harband <ljharb at gmail.com> wrote:
>
>> There's also `instanceof`.
>>
>> On Fri, Apr 14, 2017 at 11:31 PM, T.J. Crowder <
>> tj.crowder at farsightsoftware.com> wrote:
>>
>>> Happy with `neq`.
>>>
>>> > Up to date, the only keyword
>>> > operators have been exclusively unary, such as `typeof`, `await`,
>>> > and `yield`.
>>>
>>> Not quite. :-) As I mentioned when suggesting them originally, there is
>>> *one* binary non-symbolic operator already: `in`
>>>
>>> ```js
>>> if ("foo" in obj)
>>> ```
>>>
>>> So the concept of non-symbolic binary operators isn't entirely new to
>>> the parsing/grammar infrastructure.
>>>
>>> -- T.J. Crowder
>>>
>>> On Sat, Apr 15, 2017 at 4:42 AM, Isiah Meadows <isiahmeadows at gmail.com>
>>> wrote:
>>>
>>>> So far, the only decent proposal I've seen here is the keyword
>>>> operator idea. It looks operator-y, and it actually reads like what
>>>> you expect. Few nits about the general idea, and most of these would
>>>> probably keep TC39 from considering them:
>>>>
>>>> 1. `neq` is better than `noteq`. 2 fewer characters for a common
>>>> operation.
>>>>
>>>> 2. JS is a weakly typed language, and coerces nearly everything. It
>>>> normally calls `.valueOf()` (if it exists) and coerces the result to
>>>> numbers for the comparison operators. Strong type checking has
>>>> generally only been reserved for scenarios that can't be optimized
>>>> well otherwise (like the length of typed arrays) or that require
>>>> specific guarantees that coercion prevents (like uniqueness for weak
>>>> collections).
>>>>
>>>> 3. TypeScript and Flow both literally don't have this issue at all,
>>>> and several members of TC39 actively use these in mission-critical
>>>> code.
>>>>
>>>> 4. JS has historically *avoided* keyword operators, electing to remain
>>>> close-ish to its curly brace and punctuation-driven roots. Consider
>>>> `=>`, `&&` and `||`, `function *`, etc. Up to date, the only keyword
>>>> operators have been exclusively unary, such as `typeof`, `await`, and
>>>> `yield`. So this would face a potentially steep slope to acceptance.
>>>>
>>>> Just a bit of pessimistic pragmatism here.
>>>> -----
>>>>
>>>> Isiah Meadows
>>>> me at isiahmeadows.com
>>>>
>>>>
>>>> On Fri, Apr 14, 2017 at 5:33 PM, doodad-js Admin <doodadjs at gmail.com>
>>>> wrote:
>>>> > I prefer the idea of keyword operators, like :
>>>> >
>>>> >
>>>> >
>>>> > a lt 1 // strict < 1
>>>> >
>>>> > a lte 1 // strict <=1
>>>> >
>>>> > a gt 1 // strict > 1
>>>> >
>>>> > a gte 1 // strict >= 1
>>>> >
>>>> > ...
>>>> >
>>>> >
>>>> >
>>>> > That’s easier to understand and memorize.
>>>> >
>>>> >
>>>> >
>>>> > From: Dawid Szlachta [mailto:dawidmj.szlachta at gmail.com]
>>>> > Sent: Friday, April 14, 2017 5:12 AM
>>>> > To: Jordan Harband <ljharb at gmail.com>
>>>> > Cc: es-discuss <es-discuss at mozilla.org>
>>>> > Subject: Re: Re: Strict Relational Operators
>>>> >
>>>> >
>>>> >
>>>> > [...]
>>>> >
>>>> >
>>>> >
>>>> > The =@=@= operator is probably easier to add and won't break the web.
>>>> Also,
>>>> > some basic pattern matching for functions would be useful and time
>>>> saving
>>>> > feature:
>>>> >
>>>> >
>>>> >
>>>> > [...]
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20170415/8adef231/attachment.html>