New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

invert sense of ? with compound assignment #969

Merged
merged 1 commit into from Jun 26, 2017

Conversation

Projects
None yet
2 participants
@rhendric
Collaborator

rhendric commented Jun 19, 2017

The code a ?= b is basically a? || a = b, which is all well and good; it makes sense to want to assign to a if it's nullish.

However, prior to this commit, the code a ?+= b was basically a? || a += b, which is useless. If a is nullish, I certainly don't want to add anything to it.

Contrast with accessignment, where a?=b is basically a? && a.=b. Obviously better this way.

This commit makes a ?_= b mean a? && a _= b, as with accessignment, for any compound assignment operator. (a ?= b and a ?:= b are unchanged.)

Technically a breaking change, but I don't see how the feature would have been put to any good use before, so I'm treating this as a minor bug fix and waiting one week before merging on June 26, unless, as always, there are objections.

invert sense of ? with compound assignment
The code `a ?= b` is basically `a? || a = b`, which is all well and
good; it makes sense to want to assign to `a` if it's nullish.

However, prior to this commit, the code `a ?+= b` was basically `a? || a
+= b`, which is useless. If `a` is nullish, I certainly don't want to
add anything to it.

Contrast with accessignment, where `a?=b` is basically `a? && a.=b`.
Obviously better this way.

This commit makes `a ?_= b` mean `a? && a _= b`, as with accessignment,
for any compound assignment operator. (`a ?= b` and `a ?:= b` are
unchanged.)
@vendethiel

This comment has been minimized.

Contributor

vendethiel commented Jun 20, 2017

Which case does this serve that &&_= doesn't? Maybe we should just forbid it.

@rhendric

This comment has been minimized.

Collaborator

rhendric commented Jun 20, 2017

? and && differ on falsy-but-not-nullish values (0 and the empty string). So

actor.health ?+= 10

increments actor’s health if it exists (even if it's 0), whereas

actor.health &&+= 10

only does so if actor has a nonzero health.

I feel like there are at least as many, if not more, use cases for the former as for the latter.

Again, I'm shooting for consistency with what accessignment does: compare actor.health?=add 10, if health for some reason is an object with an add method instead of a primitive number. Forbidding this with operators but permitting it with accessignment doesn't make a lot of sense to me, though I'm open to arguments that, e.g., the operator version is more confusing for some reason.

@vendethiel

This comment has been minimized.

Contributor

vendethiel commented Jun 20, 2017

I'm not too happy on a ?= b being different from a?=b either, tbh. I know why it's different, but I think requiring an explicit a?.=b isn't too bad.

@rhendric

This comment has been minimized.

Collaborator

rhendric commented Jun 20, 2017

That seems like a completely independent question—or am I missing your point? Even with the explicit dot, a ?.= b does nothing if a is nullish, and I'm making the case that a ?+= b should similarly do nothing if a is nullish—basically, compound assignment operators are more like accessignment then they are like simple assignment, in that they both read and write the LHS. Any further concerns about that?

@vendethiel

This comment has been minimized.

Contributor

vendethiel commented Jun 20, 2017

No, that's a completely independent point indeed.
I'm fine with this PR as-is, I only have doubts that it won't actually be used.

@rhendric rhendric merged commit 8024b39 into gkz:master Jun 26, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

This was referenced Jan 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment