{"action":"opened","issue":{"url":"https://api.github.com/repos/rust-lang-nursery/fmt-rfcs/issues/11","repository_url":"https://api.github.com/repos/rust-lang-nursery/fmt-rfcs","labels_url":"https://api.github.com/repos/rust-lang-nursery/fmt-rfcs/issues/11/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang-nursery/fmt-rfcs/issues/11/comments","events_url":"https://api.github.com/repos/rust-lang-nursery/fmt-rfcs/issues/11/events","html_url":"https://github.com/rust-lang-nursery/fmt-rfcs/issues/11","id":178241869,"number":11,"title":"Statements","user":{"login":"nrc","id":762626,"avatar_url":"https://avatars.githubusercontent.com/u/762626?v=3","gravatar_id":"","url":"https://api.github.com/users/nrc","html_url":"https://github.com/nrc","followers_url":"https://api.github.com/users/nrc/followers","following_url":"https://api.github.com/users/nrc/following{/other_user}","gists_url":"https://api.github.com/users/nrc/gists{/gist_id}","starred_url":"https://api.github.com/users/nrc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nrc/subscriptions","organizations_url":"https://api.github.com/users/nrc/orgs","repos_url":"https://api.github.com/users/nrc/repos","events_url":"https://api.github.com/users/nrc/events{/privacy}","received_events_url":"https://api.github.com/users/nrc/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-09-21T04:13:49Z","updated_at":"2016-09-21T04:13:49Z","closed_at":null,"body":"Decide on rules for statements (deliberately excluding expressions and items for now)\r\n\r\nIn general, statements should be on their own line and any comments should be on the previous line. Avoid comments inside statements. Attributes are left for another issue.\r\n\r\n## `let` declarations\r\n\r\nThe formatting of patterns, types, and expressions is left for other issues. There should be spaces after the `:` and on both sides of the `=` (if they are present). No space before the semi-colon.\r\n\r\n```\r\n// A comment.\r\nlet pattern: Type = expr;\r\n\r\nlet pattern;\r\nlet pattern: Type;\r\nlet pattern = expr;\r\n```\r\n\r\nIf possible the declaration should be formatted on a single line. If this is not possible, then try splitting after the `=`, if the declaration can fit on two lines. The expression should be block indented.\r\n\r\n```\r\nlet pattern: Type =\r\n    expr;\r\n```\r\n\r\nIf the first line does not on a single line, then split after the colon, both the type and expression are block indented (and start new block indenting contexts) If pattern spans multiple lines, then it should be visually indented:\r\n\r\n```\r\nlet pattern:\r\n    Type =\r\n    expr;\r\n```\r\n\r\ne.g,\r\n\r\n```\r\nlet Foo {\r\n        f: abcd,\r\n        g: qwer,\r\n    }:\r\n    Foo<Bar> =\r\n    Foo { f: a, g: b };\r\n\r\nlet (abcd,\r\n     defg):\r\n    Baz =\r\n{ ... }\r\n```\r\n\r\nAlternative: the pattern could be block indented or not indented at all. I think it is very rare to have multi-line patterns, so it is not so important (and might be affected by how we format patterns themselves).\r\n\r\nIf the expression covers multiple lines, if the first line of the expression fits in the remaining space, it stays on the same line as the `=`, the rest of the expression is not indented. If the first line does not fit, then it should start on the next lines, and should be block indented. If the expression is a block and the\r\ntype or pattern cover multiple lines, then the opening brace should be on a new line and not indented (this provides separation for the interior of the block from the type), otherwise the opening brace follows the `=`.\r\n\r\nExamples:\r\n\r\n```\r\nlet foo = Foo {\r\n    f: abcd,\r\n    g: qwer,\r\n};\r\n\r\nlet foo =\r\n    ALongName {\r\n        f: abcd,\r\n        g: qwer,\r\n    };\r\n\r\nlet foo: Type = {\r\n    an_expression();\r\n    ...\r\n};\r\n\r\nlet foo:\r\n    ALongType =\r\n{\r\n    an_expression();\r\n    ...    \r\n};\r\n```\r\n\r\n## macro in statement position\r\n\r\na macro use in statement position should use parentheses as delimiters and should be terminated with a semi-colon. There should be no spaces between the name, `!`, the delimiters, or the `;`. How to format any tokens passed to the macro is left for a macro-specific issue.\r\n\r\n```\r\n// A comment.\r\na_macro!(...);\r\n```\r\n\r\n## expressions in statement position\r\n\r\nThere should be no space between the expression and the semi-colon.\r\n\r\n```\r\n<expr>;\r\n```\r\n\r\nAll expressions in statement position should be terminated with a semi-colon, unless they end with a block or are used as the value for a block.\r\n\r\nE.g.,\r\n\r\n```\r\n{\r\n    an_expression();\r\n    expr_as_value()\r\n}\r\n\r\nreturn foo();\r\n\r\nloop {\r\n    break;\r\n}\r\n```\r\n\r\nNote that `let` declarations have a semicolon of their own.\r\n\r\nUse a semi-colon where an expression has void type, even if it could be propagated. E.g.,\r\n\r\n```\r\nfn foo() { ... }\r\n\r\nfn bar() {\r\n    foo();\r\n}\r\n```"}}
{"actor":{"display_login":"nrc"}}