{"action":"created","issue":{"url":"https://api.github.com/repos/WebAssembly/design/issues/518","labels_url":"https://api.github.com/repos/WebAssembly/design/issues/518/labels{/name}","comments_url":"https://api.github.com/repos/WebAssembly/design/issues/518/comments","events_url":"https://api.github.com/repos/WebAssembly/design/issues/518/events","html_url":"https://github.com/WebAssembly/design/issues/518","id":127344246,"number":518,"title":"Nop in branch values when the target is not expecting a value.","user":{"login":"JSStats","id":11826073,"avatar_url":"https://avatars.githubusercontent.com/u/11826073?v=3","gravatar_id":"","url":"https://api.github.com/users/JSStats","html_url":"https://github.com/JSStats","followers_url":"https://api.github.com/users/JSStats/followers","following_url":"https://api.github.com/users/JSStats/following{/other_user}","gists_url":"https://api.github.com/users/JSStats/gists{/gist_id}","starred_url":"https://api.github.com/users/JSStats/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JSStats/subscriptions","organizations_url":"https://api.github.com/users/JSStats/orgs","repos_url":"https://api.github.com/users/JSStats/repos","events_url":"https://api.github.com/users/JSStats/events{/privacy}","received_events_url":"https://api.github.com/users/JSStats/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2016-01-19T01:36:30Z","updated_at":"2016-01-20T10:31:54Z","closed_at":null,"body":"The V8 encoding uses a nop as filling in `br` operations see https://github.com/WebAssembly/sexpr-wasm-prototype/issues/20 Can the spec be modified to accept this usage?\r\n\r\nThe V8 encoding used the following pattern.\r\n```\r\n$ cat test4.wast\r\n(module\r\n  (func\r\n    (block $exit\r\n      (br $exit (nop)))))\r\n$ ./wasm  test4.wast\r\ntest4.wast:4.7-4.23: arity mismatch\r\n```"},"comment":{"url":"https://api.github.com/repos/WebAssembly/design/issues/comments/173164613","html_url":"https://github.com/WebAssembly/design/issues/518#issuecomment-173164613","issue_url":"https://api.github.com/repos/WebAssembly/design/issues/518","id":173164613,"user":{"login":"JSStats","id":11826073,"avatar_url":"https://avatars.githubusercontent.com/u/11826073?v=3","gravatar_id":"","url":"https://api.github.com/users/JSStats","html_url":"https://github.com/JSStats","followers_url":"https://api.github.com/users/JSStats/followers","following_url":"https://api.github.com/users/JSStats/following{/other_user}","gists_url":"https://api.github.com/users/JSStats/gists{/gist_id}","starred_url":"https://api.github.com/users/JSStats/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JSStats/subscriptions","organizations_url":"https://api.github.com/users/JSStats/orgs","repos_url":"https://api.github.com/users/JSStats/repos","events_url":"https://api.github.com/users/JSStats/events{/privacy}","received_events_url":"https://api.github.com/users/JSStats/received_events","type":"User","site_admin":false},"created_at":"2016-01-20T10:31:54Z","updated_at":"2016-01-20T10:31:54Z","body":"Thank you for all the feedback. It's still not clear to me that this should fail. The expected type is void or empty-values, and the expression type is the same? It seems just a bug to assume that the expression returns values without checking it.\r\n\r\n@rossberg-chromium I think we see multi-value support differently as I don't see a problem with a separate convenience opcode for the case in which there is no expression `(br label)`. The multi-value case would be `(br_exp label (values 1 2 3))` or `(br_exp label (call $fn_returning_multiple_values ..))` etc and would not be `(br_n label v1 v2 v3 ... vn)`.\r\n\r\n@lukewagner Using the parent expected type to determine the number of expressions required by a child expression sounds very unfortunate. However it would be fine for a compressor to make coding choices based on context. Please let us know when you have some sketch of an alternative binary encoding as it might take some time to evaluate and it might be unnecessary to have all the details to form some opinions - for example we can run a bottom up compression predictor and compare it to a top down predictor.\r\n\r\n@kg It might be too early to assume that 'the case where they accept a value is going to be incredibly rare compared to the no-value case' because the emitted code is just not yet optimize to take advantage of expressions at the block level. With multiple-value support the opportunities also increase."}}