{"action":"opened","issue":{"url":"https://api.github.com/repos/rust-lang/rfcs/issues/1767","repository_url":"https://api.github.com/repos/rust-lang/rfcs","labels_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1767/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1767/comments","events_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1767/events","html_url":"https://github.com/rust-lang/rfcs/issues/1767","id":181478247,"number":1767,"title":"Allow for and while loop to return value (without discussion of keyword names)","user":{"login":"JelteF","id":1162278,"avatar_url":"https://avatars.githubusercontent.com/u/1162278?v=3","gravatar_id":"","url":"https://api.github.com/users/JelteF","html_url":"https://github.com/JelteF","followers_url":"https://api.github.com/users/JelteF/followers","following_url":"https://api.github.com/users/JelteF/following{/other_user}","gists_url":"https://api.github.com/users/JelteF/gists{/gist_id}","starred_url":"https://api.github.com/users/JelteF/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JelteF/subscriptions","organizations_url":"https://api.github.com/users/JelteF/orgs","repos_url":"https://api.github.com/users/JelteF/repos","events_url":"https://api.github.com/users/JelteF/events{/privacy}","received_events_url":"https://api.github.com/users/JelteF/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-10-06T17:33:12Z","updated_at":"2016-10-06T17:33:12Z","closed_at":null,"body":"### Introduction\r\nI noticed #961 didn't seem to go anywhere because of the discussion about the name of the new block. That's why I just started working on an RFC with the new block name that IMHO seemed to have the least issues, namely the `!break` one. However, I found out a lot of behavioural details where not actually decided on or discussed.\r\n\r\n### What this discussion is about (spoiler: not names of keywords)\r\nThis is why I want to start a new thread to discuss these details **and not the names of keywords**. The names used in this issue are not meant as final keywords for an RFC. They are simply meant to allow a discussion without confusion. After the issues here are settled, the names for the keywords can be discussed again in #961 or in a new issue. \r\n\r\n\r\n### Problems\r\nThe new proposal would allow `for` and `while` to return a value with the `break` statement, just like proposed for `loop` in #1624. We need extra behaviour because `for` and `while` can exit without a break. However, this can happen in two different ways. Either the loop body is never executed (`for` with an empty iterator  or `while` with a false condition at the start). Or the body is executed at least once, reaches the end of the loop body or a `continue` statement and then the loop stops (e.g. because it's out of elements or the condition has become false).\r\n\r\n### Solutions\r\nFor the case where the body is never executed another block is required that can return a value, this block is from here on called `noloop`. For the cases where the loop would be executed I see three main solutions. These are below with short names that are used in the rest of this issue between brackets: \r\n\r\n1. Use the same `noloop` block as is use in the other case. (\"noloop\")\r\n2. Use a second new block, from here on called `nobreak`. (\"nobreak\")\r\n3. Use the value from the last statement that is executed, which can be `continue`. (\"last-statement\")\r\n\r\nThen there are also two combinations possible of the options option above:\r\n\r\n4. Make the `nobreak` block optional and \"noloop\" when it is not added. (\"nobreak-noloop\")\r\n5. Make the `nobreak` block optional and \"last-statement\" when it is not added. (\"nobreak-last-statement\")\r\n\r\n\r\n### My opinion on these solutions\r\nThe \"noloop\" option seems like the worst choice, as it does not allow to differentiate between the two different cases. The \"nobreak\" option seems better in this regard as it allows to have different behaviour for both cases, but is more verbose in cases where the behaviour should be the same. The \"nobreak-noloop\" solution allows to have different behaviour for both cases, but is concise when this is not needed.\r\n\r\nThe \"last-stament\" option has a big usability advantage over the previous ones, because it allows returning of a value used in the last iteration. However, this comes with the disadvantage that when this is not needed all possible endpoints need to return the same value, i.e. the end of the loop and all `continue` statements. With the \"nobreak-last-statement\" solution you can work around this disadvantage by using the `nobreak` block. \r\n\r\nThis reasoning is why I think the solutions can be ordered from most desirable to least in the following order:\r\n\r\n1. \"nobreak-last-statement\"\r\n2. \"last-stament\"\r\n3. \"nobreak-noloop\"\r\n4. \"nobreak\"\r\n5. \"noloop\"\r\n\r\nPlease comment if you have other ideas that could be used, or you have a different opinion en the proposed solutions."}}
{"actor":{"display_login":"JelteF"}}