proposal-nullish-coalescing VS proposal-temporal

For more info about this feature, you can refer to the original proposal.

Propuesta

For comparison, here are the Javascript RFCs for the equivalent operators:

https://github.com/TC39/proposal-optional-chaining

https://github.com/tc39/proposal-nullish-coalescing

IMO optional chaining is a lifesaver when dealing with deeply nested JSON, and it's become indispensable in our Typescript code. But we also deal with JSON from various third-party endpoints in Python, and far too often we resort to an inefficient deep_get utility to make our code sensical.

> if json?.get("foo")?.get("bar")?[0]?.get("baz")

may seem messy but would be infinitely better than the fragile (note the nested list-of-a-single-dict, and how bugs can appear if it's not there):

> if json.get("foo", {}).get("bar", [{}])[0].get("baz")

or the inefficient

> if deep_get(json, "foo.bar.0.baz")

It's not nearly as good as the Typescript json.foo?.bar?.[0]?.baz - but it's good enough!

The nullish coalescing proposal provides a way to handle undefined or null values and provide default values for the expression. You can use the “??” operator to provide a default value for an expression.

Even with the initial pitfalls of JavaScript dates, the ecosystem managed to tackle those challenges with good libraries. Some use the native JavaScript date while others have instead created their own robust tools to make up for the quirks JavaScript dates might have. With the JavaScript Temporal API about to roll out, working with dates and time in JavaScript will only improve.

Temporal API

In the TypeScript/JavaScript world the only thing called "Temporal" that I was aware of is the Stage 3 proposal for an excellent new date and time module:

https://tc39.es/proposal-temporal/docs/

Time Zone Canonicalization: Stacked on Temporal to improve handling of changes to the IANA Time Zone Database.