Optional assignment operator

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Optional assignment operator

Jacob Pratt
I've been having this thought recently, after running across a potential use case in practice. There will likely be conditional accessors at some point in the future (with optional chaining), but there will not be conditional assignment.

My thought was to have the following:
    this.foo ?= params?.foo;
which can be desugared to
    if (($ref = params?.foo) !== undefined) { this.foo = $ref; }

I would strictly check for undefined, rather than nullish, as anything other than undefined would indicate that a value is present that can be set. If no value is present (such as a missing key on an object), nothing would be set. A reference must be used for the general case, as the object being assigned (the RHS) could be a function or getter with side-effects.

Not sure if it should be ?= or =?, as it would look somewhat odd (IMO) for things like ?+= or +=?.

Initial thoughts?
Jacob Pratt

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Optional assignment operator

Sam Ruby
On Wed, Jul 4, 2018 at 7:12 PM, Jacob Pratt <[hidden email]> wrote:

> I've been having this thought recently, after running across a potential use
> case in practice. There will likely be conditional accessors at some point
> in the future (with optional chaining), but there will not be conditional
> assignment.
>
> My thought was to have the following:
>     this.foo ?= params?.foo;
> which can be desugared to
>     if (($ref = params?.foo) !== undefined) { this.foo = $ref; }
>
> I would strictly check for undefined, rather than nullish, as anything other
> than undefined would indicate that a value is present that can be set. If no
> value is present (such as a missing key on an object), nothing would be set.
> A reference must be used for the general case, as the object being assigned
> (the RHS) could be a function or getter with side-effects.
>
> Not sure if it should be ?= or =?, as it would look somewhat odd (IMO) for
> things like ?+= or +=?.
>
> Initial thoughts?

Perl and Ruby have "||=" and "&&=" operators.  They don't strictly
check for undefined in either language.

These operators are frequently used (in particular, "||=").  I do miss them.

Looking at the node.js source:

$ find . -name '*.js' -type f | xargs egrep ' (\S+) = \1 \|\| ' | wc -l
   1416

$ find . -name '*.js' -type f | xargs egrep ' if \(!(\S+)\) \1 = ' | wc -l
     497

Nearly 2K occurrences in one code base.

> Jacob Pratt

- Sam Ruby
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Optional assignment operator

Isiah Meadows-2
How about you all take a look here:
https://github.com/tc39/proposal-logical-assignment

Originally, it was at
<https://github.com/tc39/proposal-nullish-coalescing>, but here
<https://github.com/tc39/proposal-nullish-coalescing/issues/1>, it was
discussed and pushed off to the logical assignment proposal as it was
also a short-circuiting operator, even though it wasn't really a
*boolean* operator.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Wed, Jul 4, 2018 at 10:25 PM, Sam Ruby <[hidden email]> wrote:

> On Wed, Jul 4, 2018 at 7:12 PM, Jacob Pratt <[hidden email]> wrote:
>> I've been having this thought recently, after running across a potential use
>> case in practice. There will likely be conditional accessors at some point
>> in the future (with optional chaining), but there will not be conditional
>> assignment.
>>
>> My thought was to have the following:
>>     this.foo ?= params?.foo;
>> which can be desugared to
>>     if (($ref = params?.foo) !== undefined) { this.foo = $ref; }
>>
>> I would strictly check for undefined, rather than nullish, as anything other
>> than undefined would indicate that a value is present that can be set. If no
>> value is present (such as a missing key on an object), nothing would be set.
>> A reference must be used for the general case, as the object being assigned
>> (the RHS) could be a function or getter with side-effects.
>>
>> Not sure if it should be ?= or =?, as it would look somewhat odd (IMO) for
>> things like ?+= or +=?.
>>
>> Initial thoughts?
>
> Perl and Ruby have "||=" and "&&=" operators.  They don't strictly
> check for undefined in either language.
>
> These operators are frequently used (in particular, "||=").  I do miss them.
>
> Looking at the node.js source:
>
> $ find . -name '*.js' -type f | xargs egrep ' (\S+) = \1 \|\| ' | wc -l
>    1416
>
> $ find . -name '*.js' -type f | xargs egrep ' if \(!(\S+)\) \1 = ' | wc -l
>      497
>
> Nearly 2K occurrences in one code base.
>
>> Jacob Pratt
>
> - Sam Ruby
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Optional assignment operator

Jacob Pratt
This idea isn't quite the same as ||=, as that includes any falsey value, nor ??=, as that includes null. My thought was to be able to set a property if there is a value that exists (which would include null, but not undefined).

It's certainly similar — should this be considered for addition to that existing proposal?

My thinking was along the lines of "Set this if there is something to set. If not, just keep going". It can be done with an if statement, but would require a temporary reference due to getters and/or method calls.

jhpratt

On Thu, Jul 5, 2018 at 3:08 AM, Isiah Meadows <[hidden email]> wrote:
How about you all take a look here:
https://github.com/tc39/proposal-logical-assignment

Originally, it was at
<https://github.com/tc39/proposal-nullish-coalescing>, but here
<https://github.com/tc39/proposal-nullish-coalescing/issues/1>, it was
discussed and pushed off to the logical assignment proposal as it was
also a short-circuiting operator, even though it wasn't really a
*boolean* operator.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Wed, Jul 4, 2018 at 10:25 PM, Sam Ruby <[hidden email]> wrote:
> On Wed, Jul 4, 2018 at 7:12 PM, Jacob Pratt <[hidden email]> wrote:
>> I've been having this thought recently, after running across a potential use
>> case in practice. There will likely be conditional accessors at some point
>> in the future (with optional chaining), but there will not be conditional
>> assignment.
>>
>> My thought was to have the following:
>>     this.foo ?= params?.foo;
>> which can be desugared to
>>     if (($ref = params?.foo) !== undefined) { this.foo = $ref; }
>>
>> I would strictly check for undefined, rather than nullish, as anything other
>> than undefined would indicate that a value is present that can be set. If no
>> value is present (such as a missing key on an object), nothing would be set.
>> A reference must be used for the general case, as the object being assigned
>> (the RHS) could be a function or getter with side-effects.
>>
>> Not sure if it should be ?= or =?, as it would look somewhat odd (IMO) for
>> things like ?+= or +=?.
>>
>> Initial thoughts?
>
> Perl and Ruby have "||=" and "&&=" operators.  They don't strictly
> check for undefined in either language.
>
> These operators are frequently used (in particular, "||=").  I do miss them.
>
> Looking at the node.js source:
>
> $ find . -name '*.js' -type f | xargs egrep ' (\S+) = \1 \|\| ' | wc -l
>    1416
>
> $ find . -name '*.js' -type f | xargs egrep ' if \(!(\S+)\) \1 = ' | wc -l
>      497
>
> Nearly 2K occurrences in one code base.
>
>> Jacob Pratt
>
> - Sam Ruby
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Optional assignment operator

Isiah Meadows-2
You could file an issue there, where it's more likely to get seen by
interested parties. The basic concept is basically reversed augmented
assignment, where `a @= b` usually means `a = a @ b`, you'd want
something like `a =@ b` meaning `a = b @ a`. (Operator is up for
debate, and `=-` conflicts with negation.)

I could see the use of it - `??` is the most common case for me, but a
reverse subtraction or easy reciprocal division would also be
convenient in some cases. I'm neutral on the idea, though.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Thu, Jul 5, 2018 at 4:53 PM, Jacob Pratt <[hidden email]> wrote:

> This idea isn't quite the same as ||=, as that includes any falsey value,
> nor ??=, as that includes null. My thought was to be able to set a property
> if there is a value that exists (which would include null, but not
> undefined).
>
> It's certainly similar — should this be considered for addition to that
> existing proposal?
>
> My thinking was along the lines of "Set this if there is something to set.
> If not, just keep going". It can be done with an if statement, but would
> require a temporary reference due to getters and/or method calls.
>
> jhpratt
>
> On Thu, Jul 5, 2018 at 3:08 AM, Isiah Meadows <[hidden email]>
> wrote:
>>
>> How about you all take a look here:
>> https://github.com/tc39/proposal-logical-assignment
>>
>> Originally, it was at
>> <https://github.com/tc39/proposal-nullish-coalescing>, but here
>> <https://github.com/tc39/proposal-nullish-coalescing/issues/1>, it was
>> discussed and pushed off to the logical assignment proposal as it was
>> also a short-circuiting operator, even though it wasn't really a
>> *boolean* operator.
>>
>> -----
>>
>> Isiah Meadows
>> [hidden email]
>> www.isiahmeadows.com
>>
>>
>> On Wed, Jul 4, 2018 at 10:25 PM, Sam Ruby <[hidden email]> wrote:
>> > On Wed, Jul 4, 2018 at 7:12 PM, Jacob Pratt <[hidden email]>
>> > wrote:
>> >> I've been having this thought recently, after running across a
>> >> potential use
>> >> case in practice. There will likely be conditional accessors at some
>> >> point
>> >> in the future (with optional chaining), but there will not be
>> >> conditional
>> >> assignment.
>> >>
>> >> My thought was to have the following:
>> >>     this.foo ?= params?.foo;
>> >> which can be desugared to
>> >>     if (($ref = params?.foo) !== undefined) { this.foo = $ref; }
>> >>
>> >> I would strictly check for undefined, rather than nullish, as anything
>> >> other
>> >> than undefined would indicate that a value is present that can be set.
>> >> If no
>> >> value is present (such as a missing key on an object), nothing would be
>> >> set.
>> >> A reference must be used for the general case, as the object being
>> >> assigned
>> >> (the RHS) could be a function or getter with side-effects.
>> >>
>> >> Not sure if it should be ?= or =?, as it would look somewhat odd (IMO)
>> >> for
>> >> things like ?+= or +=?.
>> >>
>> >> Initial thoughts?
>> >
>> > Perl and Ruby have "||=" and "&&=" operators.  They don't strictly
>> > check for undefined in either language.
>> >
>> > These operators are frequently used (in particular, "||=").  I do miss
>> > them.
>> >
>> > Looking at the node.js source:
>> >
>> > $ find . -name '*.js' -type f | xargs egrep ' (\S+) = \1 \|\| ' | wc -l
>> >    1416
>> >
>> > $ find . -name '*.js' -type f | xargs egrep ' if \(!(\S+)\) \1 = ' | wc
>> > -l
>> >      497
>> >
>> > Nearly 2K occurrences in one code base.
>> >
>> >> Jacob Pratt
>> >
>> > - Sam Ruby
>> > _______________________________________________
>> > es-discuss mailing list
>> > [hidden email]
>> > https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss