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

finally in do-expressions #6385

Open
nicolo-ribaudo opened this Issue Oct 4, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@nicolo-ribaudo
Member

nicolo-ribaudo commented Oct 4, 2017

finally shouldn't alter the completion vaule of the try statement. You can test it using eval("body of the do expression");

https://babeljs.io/repl/build/5158/#?babili=false&browsers=&build=&builtIns=false&code_lz=G4QwTgBCELwQJgewgbwgFzAT1RATBAL4QBmAlgHYgA21OaAzEUQFCiQBGsCyam9GABZhEAd1TFiAYxDopgiAAoApgEpcAVmbkqtAQDZmhFiymIKAZ0TVlAOmqIA5opAAaCB1UBuE-yjdlUGpFACJ-XAJiHRo6XCZCEO8INnAPAKDQ8L5hMQlmGTkFFXU0LSjKGIMiRJ9TcysbeycXd08vIA&debug=false&circleciRepo=&evaluate=true&lineWrap=true&presets=es2015-loose%2Cstage-0&targets=&version=7.0.0-beta.2%2Bpr.6372

Input Code

var a = do { try { 2 } finally { 3 } }
var b = do { try { throw {} } catch (e) { 5 } finally { 6 } }

console.log(a, b);

Expected Behavior

2 5

Current Behavior

3 6

software version(s)
Babel
node
npm
Operating System
@nicolo-ribaudo

This comment has been minimized.

Show comment
Hide comment
@nicolo-ribaudo

nicolo-ribaudo Oct 4, 2017

Member

Specification: https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation (Specifically, step 3 for try-finally and step 5 for try-catch-finally)

Member

nicolo-ribaudo commented Oct 4, 2017

Specification: https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation (Specifically, step 3 for try-finally and step 5 for try-catch-finally)

@keithamus

This comment has been minimized.

Show comment
Hide comment
@keithamus

keithamus Oct 5, 2017

Member

Hey @nicolo-ribaudo thanks for this issue.

I believe the current behaviour is correct. The specification notes that in any try/finally or try/catch/finally block the finally block takes precedence if returning. Do not trust eval for semantics.

Member

keithamus commented Oct 5, 2017

Hey @nicolo-ribaudo thanks for this issue.

I believe the current behaviour is correct. The specification notes that in any try/finally or try/catch/finally block the finally block takes precedence if returning. Do not trust eval for semantics.

@keithamus

This comment has been minimized.

Show comment
Hide comment
@keithamus

keithamus Oct 5, 2017

Member

To clarify @nicolo-ribaudo; the spec says if [[Type]] is normal then let the try{} portion of the statement take precedence over the finally{} type; but in this case neither block is normaly, they are both completions of the return type (determined by the return statement.

In this case, because you have a return statement in your finally block - the [[Type]] is return (see https://tc39.github.io/ecma262/#sec-completion-record-specification-type) not normal, and so finally takes precedence.

Member

keithamus commented Oct 5, 2017

To clarify @nicolo-ribaudo; the spec says if [[Type]] is normal then let the try{} portion of the statement take precedence over the finally{} type; but in this case neither block is normaly, they are both completions of the return type (determined by the return statement.

In this case, because you have a return statement in your finally block - the [[Type]] is return (see https://tc39.github.io/ecma262/#sec-completion-record-specification-type) not normal, and so finally takes precedence.

@keithamus

This comment has been minimized.

Show comment
Hide comment
@keithamus

keithamus Oct 5, 2017

Member

Sorry I haven't been very clear here. I believe the do expression creates implicit return statements. The spec needs clarifying though. Right now it is doing nothing out of the ordinary; again, this isn't eval semantics. There's an open issue for this here: tc39/proposal-do-expressions#6

Member

keithamus commented Oct 5, 2017

Sorry I haven't been very clear here. I believe the do expression creates implicit return statements. The spec needs clarifying though. Right now it is doing nothing out of the ordinary; again, this isn't eval semantics. There's an open issue for this here: tc39/proposal-do-expressions#6

@nicolo-ribaudo

This comment has been minimized.

Show comment
Hide comment
@nicolo-ribaudo

nicolo-ribaudo Oct 5, 2017

Member

I believe the do expression creates implicit return statements.

I think they return the completion record of the block, because the proposal says "Return the result of evaluating Body." 1 (Even if it is a single line, it is the only proposed "specification" I could find).

The specification says that the result of evaluationg a block should be the result of evaluating its statements (Block: { StatementList } - steps 5 and 7), exactly like it works for eval calls (see the NOTE 2 in that section).

cc @dherman

Member

nicolo-ribaudo commented Oct 5, 2017

I believe the do expression creates implicit return statements.

I think they return the completion record of the block, because the proposal says "Return the result of evaluating Body." 1 (Even if it is a single line, it is the only proposed "specification" I could find).

The specification says that the result of evaluationg a block should be the result of evaluating its statements (Block: { StatementList } - steps 5 and 7), exactly like it works for eval calls (see the NOTE 2 in that section).

cc @dherman

@keithamus

This comment has been minimized.

Show comment
Hide comment
@keithamus

keithamus Oct 9, 2017

Member

Yeah now I think you're right - but I think it should first be resolved in tc39/proposal-do-expressions#6.

Member

keithamus commented Oct 9, 2017

Yeah now I think you're right - but I think it should first be resolved in tc39/proposal-do-expressions#6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment