Proposal: result-forwarding ternary operator

Michael Rosefield rosyatrandom at gmail.com
Thu Sep 21 11:35:14 UTC 2017


Oh, yes, but the real benefit here is that it consolidates this as a
combination of the normal ternary operator and the piping operator; an
organic synthesis of existing operators as opposed to an entirely new one
grafted on to the language.

I'd go so far as to call it the 'piping ternary operator' and make it an
extension of the piping operator proposal.

On Thu, 21 Sep 2017 at 12:22 Michał Wadas <michalwadas at gmail.com> wrote:

> Actual characters are minor issue. There are many unused combinations of
> "special" characters. Eg.
> ?> ?: :? ?() @? ?* ?# ?@ @? -? =? ?= (?) etc.
>
>
>
> On Thu, Sep 21, 2017 at 11:19 AM, Michael Rosefield <
> rosyatrandom at gmail.com> wrote:
>
>> There was a suggestion that came up in my original reddit post that I
>> think merits discussion here.
>>
>> I know one of the main arguments against this new operator is to prevent
>> needless and confusing language explosion, but u/notNullOrVoid pointed out
>> that this bears similarity to another operator already under TC39
>> consideration, the pipeline-operator (
>> https://github.com/tc39/proposal-pipeline-operator).
>>
>> My suggestion could then be implemented as follows:
>>
>> const foo = getSomething() |> x => x ? dosomething(x) : doSomethingElse();
>>
>> And this ternary could be simply a pipeline variant:
>>
>> const foo = getSomething() ?> x => dosomething(x) : doSomethingElse();
>>
>> That reads much clearer and also takes care of the syntactically invalid
>> ?! formularion.
>>
>> On Wed, 20 Sep 2017 at 14:22 Naveen Chawla <naveen.chwl at gmail.com> wrote:
>>
>>> As your example shows, for loops can be reduced to array reduction
>>> function calls. `if` `else`s can be represented by ternaries.
>>>
>>> `while` loops aren't so straightforward but can be factored into single
>>> function calls. They are less common anyway.
>>>
>>> I find single expressions listed as `(a, b, c)` more readable than code
>>> blocks who eventually evaluate to a single value each.
>>>
>>> So, even if `do` expressions were introduced into ES, I would avoid
>>> using them as much as I could, unless it were really smarter and more
>>> readable to use them than any of the alternatives
>>>
>>> On Wed, 20 Sep 2017 at 16:11 T.J. Crowder <
>>> tj.crowder at farsightsoftware.com> wrote:
>>>
>>>> On Wed, Sep 20, 2017 at 11:28 AM, Naveen Chawla <naveen.chwl at gmail.com>
>>>> wrote:
>>>> >
>>>> > The comma operator seems to make the `do` concept redundant, at
>>>> > least for me.
>>>>
>>>> No, not at all. Again: With the comma operator, you can't use
>>>> *statements*, only expressions. With the `do` expression, you can use
>>>> actual statements:
>>>>
>>>> ```js
>>>> const x = do {
>>>>     for (const x of getTheThings()) {
>>>>         if (x.id == something) {
>>>>             x.foo;
>>>>         }
>>>>     }
>>>> };
>>>> ```
>>>>
>>>> ...which is basically:
>>>>
>>>> ```js
>>>> const x = getTheThings().find(x => x.id == something).foo;
>>>> ```
>>>>
>>>> ...except it doesn't throw if `find` returns `undefined`, and isn't a
>>>> series of function calls.
>>>>
>>>> `do` expressions are basically to address overly-complex conditional
>>>> expressions and IIFEs.
>>>> More: https://gist.github.com/dherman/1c97dfb25179fa34a41b5fff040f9879
>>>>
>>>> -- T.J. Crowder
>>>>
>>>> _______________________________________________
>>> 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/20170921/51b97486/attachment-0001.html>


More information about the es-discuss mailing list