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

Optional Chaining Operator (Stage 1) #18

Closed
hzoo opened this issue Jul 27, 2017 · 9 comments
Closed

Optional Chaining Operator (Stage 1) #18

hzoo opened this issue Jul 27, 2017 · 9 comments

Comments

@hzoo
Copy link
Member

hzoo commented Jul 27, 2017

Champion: @gisenberg
Spec Repo: https://github.com/gisenberg/proposal-optional-chaining
Stayed at Stage 1 at the July 2017 meeting: https://docs.google.com/presentation/d/1OcytQtyykmOZJwm-LFgOP0FpQccyeajAjLdOvBki9a0/
Stayed at Stage 1 at the Sept 2017 meeting: https://docs.google.com/presentation/d/1iiCtJSW42Z7lg0YlagOZOfI-FTrkN88OuiO3pySawSo/edit?usp=sharing

Syntax

a?.b

Implementation

@littledan
Copy link

littledan commented Aug 3, 2017

Note that the issue of contention at TC39 was the "short-circuiting" semantics. See this issue for details: tc39/proposal-optional-chaining#10 . Previously, the specification was option 4. The specification was changed to option 2 based on online feedback.

The committee seemed to be advocating option 1, but it's unclear if they had a good understanding of the CoffeeScript data or the way other programming languages work here.

These differences matter for both parsing and the transform, though there may be some design that handles the parsing in a single way among all options.

Maybe Babel could implement multiple of these options and become a place where the differences could be explored interactively by programmers.

@hzoo
Copy link
Member Author

hzoo commented Aug 3, 2017

@littledan if it moves the proposal forward (worth implementing both for someone) we could have options - to convince people one is better than the other.

@ljharb
Copy link
Member

ljharb commented Aug 3, 2017

The only concern there is that it turns a likelihood of someone shipping untranspiled code using eventually-wrong semantics into a certainty.

@hzoo
Copy link
Member Author

hzoo commented Aug 3, 2017

@ljharb this is for stage-0, and we are happy to break whenever if we aren't sure of the semantics. Maybe in these cases we have a warning. I don't think we do need to implement both actually, just show the input/output

@littledan
Copy link

I don't see this as having a higher risk than many of the other proposals that Babel has implemented at Stage 1. I think @hzoo has done a good job communicating clearly that Stage 1 and 2 are highly unstable.

@littledan
Copy link

Anyway, I'm not sure if anyone would really use the various alternatives, it just might be an interesting way to get feedback.

@hzoo
Copy link
Member Author

hzoo commented Aug 3, 2017

Yeah and if we do implement multiple versions, it's definetely not an intention in any way to be used other than for feedback for the proposal itself.

@morsmodr
Copy link

Is there any progress in this? Currently from here: https://github.com/babel/proposals I see that the Readme.md has not been updated in a long while. The proposal is in stage 4 which means it should be part of preset-env but as per the proposals link I shared, optional chaining is supposed to be in babel-preset-stage-1?

Is there a way to confirm this has indeed been added to preset-env?

@JLHwung
Copy link

JLHwung commented Nov 24, 2020

it should be part of preset-env

Yes, optional-chaining is already included in @babel/preset-env 7.12. Please refer to TC39 proposals repo for latest status: https://github.com/tc39/proposals the Babel proposals repo may be out of date.

Closing this issue as it has been supported by @babel/preset-env

@JLHwung JLHwung closed this as completed Nov 24, 2020
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