Skip to content
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

Should grouping parentheses as in (a?.b) interrupt short-circuiting? #19

Closed
claudepache opened this issue Jun 8, 2017 · 7 comments
Closed

Comments

@claudepache
Copy link
Owner

That is, should

(a?.b).c

be equivalent to

(1) (a == null ? undefined : a.b).c

rather than

(2) a?.b.c, or (a == null ? undefined : a.b.c) (as currently specced)?

As currently specced, grouping parentheses are transparent w.r.t. Nil references: this is consistent with how References work, but it is not necessarily a desirable consistency, as the Nil reference is a spec mechanism that the average user does not need to know.

One may rather want to make the semantics more similar to how short-circuiting or conditional evaluation works with other operators that have such a feature, namely ||, &&, and ? :.

Any feedback is welcome. What is more intuitive, (1) or (2)?

@Mouvedia
Copy link

Mouvedia commented Jun 8, 2017

In that peculiar example I think that (a?.b).c and a?.b.c are equivalent.

What is more intuitive, (1) or (2)?

2

@MaienM
Copy link

MaienM commented Jul 17, 2017

1

@saschanaz
Copy link

1 for me.

@Wedvich
Copy link

Wedvich commented Jul 19, 2017

To me 1 is the most intuitive - I would expect it to work the same way as the other short-circuiting operators mentioned.

@claudepache
Copy link
Owner Author

I have chosen option 1.

@Mouvedia
Copy link

So you prefer to throw a TypeError over returning undefined. I wonder why would you do that example in the first place then.

claudepache added a commit that referenced this issue Jul 21, 2017
* Update to the most recent spec version.
* Statically forbid use in contexts like `a?.b = c` (but not `delete
a?.b`). Closes #4, closes #18.
* Remove short-circuiting piercing parentheses. Closes #19.
* Minor bugfixes.
@claudepache claudepache reopened this Jul 22, 2017
claudepache added a commit that referenced this issue Jul 22, 2017
There is no strong reason for one way or the other. So, arbitrarily
choose the simpler and most consistent solution from the spec's point
of view. Fixes #19 again
@claudepache
Copy link
Owner Author

@Mouvedia Regardless of the semantics, there is hardly a practical reason to use parentheses in this situation anyway.

claudepache added a commit that referenced this issue Jul 22, 2017
There is no strong reason for one way or the other. So, arbitrarily
choose the simpler and most consistent solution from the spec's point
of view. Fixes #19 again
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants