Example implementation using Typescript

[Arlen22]

In order to give a better example of how this operator would work, I've implemented it in TypeScript.

You can download the typescript-*.tar.gz file from https://github.com/Arlen22/TypeScript/releases and then npm install the file in your project to use it.

If you're using VSCode you can change which version of TypeScript it uses for intellisense by clicking on TypeScript in the status bar.

It should compile to working JavaScript. Check the releases page for known issues.

I'm NOT a TypeScript maintainer. Do NOT use this example for production code.

Notes

Branch: https://github.com/Arlen22/TypeScript/tree/arlen22-0.2

I implemented it to have the same precedence as the yield operator.

[Arlen22]

The details are basically that when it encounters the try keyword, it first tries to parse it as a statement, then as an expression, unless it's already in an expression context, in which case it parses it as an expression (curly braces become objects).

I'm not sure I like that last part. I think curly braces should be an error unless they are surrounded by parentheses. But this sounds like all the other edge cases we're debating here, and a simple predictable language is better than one with random guarded edges. That's more what linters are for. But it could be a source of unending confusion in this case, so it might be a good idea.

I haven't tested any unusual parts of Javascript yet, like using or for loops.

[Arlen22]

For actual implementation in TypeScript, I think this should be converted to a self-executing function that returns the appropriate values. It's pretty standard for various syntax types to be converted into helper functions until they are implemented in Javascript.

I'll probably do that sometime in this example.

[arthurfiorette]

Hey @Arlen22, could you test if it aligns with the new rewriting?

#53

[Arlen22]

@arthurfiorette well, technically the parsing would still work. You'd have to edit the Result type. But I copied the code for the await and yield keywords, so it's valid for all expressions, not just the assignment expression. If I was going to do it again for the new proposal, I'd do it as a modifier of the assignment operator.

[Arlen22]

@arthurfiorette, I've updated it to fix a few things and add working JavaScript. Compiled code should be able to run properly.

The compiler basically generates a custom inline function that changes based on whether yield and await are used in the wrapped expression. It's probably not perfect.

[Lookwe69]

One word, thanks for the proposal !

For my part, I implemented a version of the proposal with a function (in a package).
It handles both synchronous and asynchronous operations. It can be useful for testing the result object.

Github
NPM

[Arlen22]

@Lookwe69 Nice. You might want to take a look at #69 (comment) which handles the other scenarios the try operator may find itself in.

[DScheglov]

@arthurfiorette

I ran into an odd issue with my own package (do-try-tuple) while trying to swap out Object.assign([ok, error, value], { ok, error, value }) for a class with a custom [Symbol.iterator] method.

Here’s a quick example:

class Ok {
    constructor(value) {
        this.value = value;
    }
    get ok() { return true; }
    get error() { return false; }
    *[Symbol.iterator]() {
        yield true;
        yield undefined;
        yield this.value;
    }
}

const ok = (value) => new Ok(value);

console.log(
  ok(1)[0] // prints `undefined`, but the types say it should be `true`
);

I checked out the try library too — it has the same problem.

There are a few ways to work around this, but they all mess up how the result gets printed:

• Returning new Proxy(this, {...}) from the constructor shows just "Proxy" in the console.
• Extending from Array gives you an array-looking object. It’s not the worst, but definitely not as nice as Ok { value: 1 }.

So, it looks like access by index should be covered by the proposal, and perhaps inspection printing should be covered as well.

UPDATE:
I've found a relatively graceful way to resulve it:

class Ok {
    constructor(value) {
        this.value = value;
    }
    get ok() {
        return true;
    }
    get [0]() {
        return true;
    }
    get error() {
        return undefined;
    }
    get [1]() {
        return undefined;
    }
    get [2]() {
        return this.value;
    }
    *[Symbol.iterator]() {
        yield true;
        yield undefined;
        yield this.value;
    }
}

So, it makes sense just update the polyfill.

[arthurfiorette]

The problem is that typings shouldn't allow for result[0], result[1] and result[2] as it makes no sense to write such code. Its there for now until typescript finds a way to declare iterators with different return types for each iteration.

[DScheglov]

it makes no sense to write such code.

Why does it makes no sense?
I'm not sure about that

[ljharb]

Because it's iterable, and iterables aren't necessarily indexable.

[DScheglov]

Because it's iterable, and iterables aren't necessarily indexable.

We have React with the hooks. The proposal offer the similar practive, but with React hooks it is possible to access by index.
So, the access by index must be discussed and the covered by proposal

[ljharb]

I'm not sure that's always true - react hooks don't have to return an array, as far as I know, just an iterable. Either way, I'm not sure why the language would ever be constrained by something React does?