There is no conflict with the using proposal, but they relate

[Arlen22]

const result = try expr1;

This proposal would augment the using proposal, not conflict with it. When both keywords are used, the using expression would attach to the value of result.ok Since the using proposal explicitly ignores a using expression which returns null or undefined, using undefined for result.ok would in no way conflict, since that is already explicitly allowed by that proposal.

Furthermore, according to await using the using proposal does not care what the assignment expression is (it could be another local variable), so expanding its semantics to operate on result.ok of a try assignment should not affect it.

Furthermore, the using proposal does not address what happens when an error is thrown by the dispose function. I'm assuming it would throw from just inside the block as the last statement of the block but it means you can't wrap the disposal in a try catch without wrapping the entire block. It certainly does not expect a try keyword within the block to handle the dispose function.

The using proposal throws if the disposable does not have a dispose function.

The position of the try keyword should determine whether or not this error gets caught by the try keyword.

These should definitely catch the error thrown by using.

try [ok, error, disposable] = await something(); // "like using" option
try using [ok, error, disposable] = await something(); // combined with using
try await using [ok, error, disposable] = await something(); // combined with await using

These should not catch the error thrown by using.

using [ok, error, disposable] = try await something(); // "like throw" option with using
using try [ok, error, disposable] = await something(); // combined with using
await using try [ok, error, disposable] = await something(); // combined with await using

#62 also relates to this decision

[arthurfiorette]

I guess Result could proxy access to value[Symbol.asyncResource] and value[Symbol.resource].

this way using [ok, error, resource] = try createResource() would work flawlessly.

Are you up to PR this into polyfill.js and README.md?

[Arlen22]

I guess Result could proxy access to value[Symbol.asyncResource] and value[Symbol.resource].

this way using [ok, error, resource] = try createResource() would work flawlessly.

That wouldn't work because using requires the value to have the relevant symbol unless the value is null or undefined, in which case it ignores everything. So using will have to be aware of the try operator's value.

[arthurfiorette]

A statement being aware of what is generating the value it's being assigned to doesn't have precedents in any other proposal as far as I know. I agree with what you said above but I'm concerned it may mean that both won't be used together.

[arthurfiorette]

Maybe extend the capabilities of using to check for Symbol.disposable on expr1.value instead of expr1 like usual?

using resource = expr1;

maybe if expr1 instanceof Result it could do a expr1.value under the hood or in case of error, simply behave like a const. but a runtime check for instanceof Result on every execution seems a bit of a no go for me...

[Arlen22]

Putting the using declaration on a separate line isn't a big deal. Trying to make them work together could start to get very complicated. Especially since we're going the try expression route now with #65.