Although I’m unsure if this is wise given there are already eleven symbols
that are combinations of `=` and `<`/`>`, for symmetry with `==` and `===`
I’d imagine something like this:

```
COERCIVE  STRICT
>         =>=
<         =<=
>=        =>==
<=        =<==
```

Could also follow the pattern `>==` (strict GT) and `<===` (strict GTE),
which avoids the awkwardness of the latter two sharing opening chars with
`=>`, but that seems more ambiguous since `>==` doesn’t let you infer
whether it means strict GT or strict GTE.

It’d be nice to have this functionality built in, but I wonder if it’d
possibly be preferable to provide it through methods of one of the built-in
objects, rather than as operators. Functions after all are more flexible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170411/e1955370/attachment-0001.html>

Although I’m unsure if this is wise given there are already eleven symbols that are combinations of `=` and `<`/`>`, for symmetry with `==` and `===` I’d imagine something like this:

```
COERCIVE  STRICT  OR MAYBE
>         =>=     ==>
<         =<=     ==<
>=        =>==    ==>=
<=        =<==    ==<=
```

Could also follow the pattern `>==` (strict GT) and `>===` (strict GTE), which avoids the awkwardness of the first and third ones sharing opening chars with `=>`, but that seems more ambiguous since `>==` doesn’t let you infer whether it means strict GT or strict GTE.

It’d be nice to have this functionality built in, but I wonder if it’d possibly be preferable to provide it through methods of one of the built-in objects, rather than as operators. Functions after all are more flexible.

Although I’m unsure if this is wise given there are already eleven symbols that are combinations of `=` and `<`/`>`, for symmetry with `==` and `===` I’d imagine something like this:

```
COERCIVE  STRICT
>         =>=
<         =<=
>=        =>==
<=        =<==
```

Could also follow the pattern `>==` (strict GT) and `<===` (strict GTE), which avoids the awkwardness of the first and third ones sharing opening chars with `=>`, but that seems more ambiguous since `>==` doesn’t let you infer whether it means strict GT or strict GTE.

It’d be nice to have this functionality built in, but I wonder if it’d possibly be preferable to provide it through methods of one of the built-in objects, rather than as operators. Functions after all are more flexible.

Although I’m unsure if this is wise given there are already eleven symbols that are combinations of `=` and `<`/`>`, for symmetry with `==` and `===` I’d imagine something like this:

```
COERCIVE  STRICT
>         =>=
<         =<=
>=        =>==
<=        =<==
```

Could also follow the pattern `>==` (strict GT) and `<===` (strict GTE), which avoids the awkwardness of the third one sharing opening chars with `=>`, but that seems more ambiguous since `>==` doesn’t let you infer whether it means strict GT or strict GTE.

It’d be nice to have this functionality built in, but I wonder if it’d possibly be preferable to provide it through methods of one of the built-in objects, rather than as operators. Functions after all are more flexible.

Although I’m unsure if this is wise given there are already eleven symbols that are combinations of `=` and `<`/`>`, for symmetry with `==` and `===` I’d imagine something like this:

```
COERCIVE  STRICT
>         =>=
<         =<=
>=        =>==
<=        =<==
```

Could also follow the pattern `>==` (strict GT) and `<===` (strict GTE), which avoids the awkwardness of the latter two sharing opening chars with `=>`, but that seems more ambiguous since `>==` doesn’t let you infer whether it means strict GT or strict GTE.

It’d be nice to have this functionality built in, but I wonder if it’d possibly be preferable to provide it through methods of one of the built-in objects, rather than as operators. Functions after all are more flexible.