return?

[kripken]

The exports.wast testcase has a "return" opcode. Is that part of the spec?

[kg]

Hm, it's not in AstSemantics. I think it was before - but there have also been discussions of removing return in favor of break-with-value, so maybe that was finalized?

[drom]

Strange, I still can see it in here: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#control-flow-structures

[kg]

Yeah, there it is. I guess GitHub repository search doesn't actually work. :|

[kripken]

Ah, I thought a previous discussion said we didn't have it anymore, I must have misunderstood. I guess we were just considering removing it.

[titzer]

I actually went all the way and removed it from v8-native, since
break-with-value subsumes it. However, in terms of usability, return is
really nice, so I kind of miss it.

On Fri, Nov 6, 2015 at 8:49 AM, Alon Zakai notifications@github.com wrote:

Ah, I thought a previous discussion said we didn't have it anymore, I must
have misunderstood. I guess we were just considering removing it.

—
Reply to this email directly or view it on GitHub
#164 (comment).

[jcbeyler]

Forget usability and say "readability". I have currently left it in my wasm-to-llvm prototype because I find it so much easier to read :)

[titzer]

It is also still in the design repo, so I plan to add it back to v8-native.

On Tue, Nov 10, 2015 at 6:21 PM, jcbeyler notifications@github.com wrote:

Forget usability and say "readability". I have currently left it in my
wasm-to-llvm prototype because I find it so much easier to read :)

—
Reply to this email directly or view it on GitHub
#164 (comment).

[sunfishcode]

I don't have an opinion yet, but a few observations:

It's in the design repo, but only because it predates statements=expressions, and the design hasn't been updated for that change in general.

Return is non-compositional, for what that's worth.

If the goal is just to make code more readable, an only slightly weaker effect could be achieved by using the existing label name syntax sugar and naming the return label "$return". Disassemblers could do this automatically if they wanted.

[titzer]

My experience has been that expressing break as return from the outermost
block has been quite tricky. It'd be less of a burden if we were to specify
that every function body is wrapped in an implicit block from which one can
break, but it's still uncomfortably error-prone. Return is
non-compositional across inlining, but still composable within a function
body (i.e. moving an AST that contains a return within a function doesn't
require updating the return). Viewed as labels, return implicitly binds to
the topmost label of the function, and thus is not a free label variable.

On Wed, Nov 11, 2015 at 12:40 AM, Dan Gohman notifications@github.com
wrote:

I don't have an opinion yet, but a few observations:

It's in the design repo, but only because it predates
statements=expressions, and the design hasn't been updated for that change
in general.

Return is non-compositional, for what that's worth.

If the goal is just to make code more readable, an only slightly weaker
effect could be achieved by using the existing label name syntax sugar and
naming the return label "$return". Disassemblers could do this
automatically if they wantef

—
Reply to this email directly or view it on GitHub
#164 (comment).

[rossberg]

Return stays, closing.

[sunfishcode]

For the record, I don't feel this is really settled yet; it's just something we're not really ready to explore while we have so many open questions about the nature of the text format(s).

[rossberg]

@sunfishcode, fair enough. I interpret this specific bug as being about the divergence between spec repo and design doc, which seems resolved for the time being.