Prior art to safe assignment operator proposal

[coderaiser]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Versions

I like the idea of assignment operator,

const [parseError, json] ?= await response.json()

It is even better then new keyword try in a couple of ways:

1. You never should guess where to put await expression

// most likely this is the only correct way, since we wrapping await
// with try expression;
const [parseError, json] = try await response.json();

// anyways most likely there will be such cases, and this will be syntax error
// on Babel, ESLint and Typescript
// or runtime error when json has promise, instead of result
const [parseError, json] = await try response.json();

2. Very easy to parse, since it most likely will be something like:

With the name SafeAssignmentExpression, or something like this. It is easier to implement in parsers then override try keyword (which is also possible).

A couple years ago I wrote:

• try-catch
• try-to-catch

They uses similar approach but works in all JavaScript engines:

const [error, result] = tryCatch(parse, 'hello');

Also I wrote a proposal which has list of modules, that uses similar approach, and share it on ES forum, there is a lot so idea is popular. Maybe you can reuse some of this information in your proposal.

Also there is implementation of transforming try expression to tryCatch in goldstein which you can try and reuse.

Just added support of safe operator to goldstein here is how it looks like:

const [error, result] ?= hello('world');

transformed to:

import tryCatch from 'try-catch';

const [error, result] = tryCatch(hello, 'world');

Thank you for you work on a proposal, I hope one day it will be part of JavaScript!

[rkrx]

It is even better then new keyword try in a couple of ways

In one way it's not. With a try keyword, you can inline unsafe calls.

Given that the error is the first tuple index in the result and is either null or undefined and that you can write something like const [error, result] = try someFn();, you could do this:

[fn1, fn2, fn3].map(fn => try fn()).filter(err => err === null) ...

x = try y can do everything, x ?= y could do and you don't need another dependency like 'try-catch'.

You never should guess where to put await expression

I don't think this is a real issue.

[arthurfiorette]

In one way it's not. With a try keyword, you can inline unsafe calls.

No you can't. The same way throw is not valid in the example you brought up.

[rkrx]

@arthurfiorette Depends on the implementation. try x could be implemented as a functional expression which returns a tuple or [Error|null, any] and is similar to the tryCatch(...)-example which exists in various forms. x ?= y would be an alternative assignment operator.

[arthurfiorette]

Depends on the implementation.

Sure, that's the reason of a proposal :) But im more in favor of a throw like exactly to avoid expressions like .map(fn => try fn()). However being able to .map(fn => try fn()) might be good as well, having a Function[] type is bad either way, so i'm not sure if we should try to prevent this usage.