{"action":"created","issue":{"url":"https://api.github.com/repos/elm-lang/elm-plans/issues/6","labels_url":"https://api.github.com/repos/elm-lang/elm-plans/issues/6/labels{/name}","comments_url":"https://api.github.com/repos/elm-lang/elm-plans/issues/6/comments","events_url":"https://api.github.com/repos/elm-lang/elm-plans/issues/6/events","html_url":"https://github.com/elm-lang/elm-plans/issues/6","id":94869842,"number":6,"title":"Proposal: Merge two-way and multi-way `if`","user":{"login":"Apanatshka","id":1237863,"avatar_url":"https://avatars.githubusercontent.com/u/1237863?v=3","gravatar_id":"","url":"https://api.github.com/users/Apanatshka","html_url":"https://github.com/Apanatshka","followers_url":"https://api.github.com/users/Apanatshka/followers","following_url":"https://api.github.com/users/Apanatshka/following{/other_user}","gists_url":"https://api.github.com/users/Apanatshka/gists{/gist_id}","starred_url":"https://api.github.com/users/Apanatshka/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Apanatshka/subscriptions","organizations_url":"https://api.github.com/users/Apanatshka/orgs","repos_url":"https://api.github.com/users/Apanatshka/repos","events_url":"https://api.github.com/users/Apanatshka/events{/privacy}","received_events_url":"https://api.github.com/users/Apanatshka/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/elm-lang/elm-plans/labels/proposal","name":"proposal","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-07-14T05:17:08Z","updated_at":"2015-07-14T05:27:50Z","closed_at":null,"body":"(I thought that would sound friendlier than \"Remove\" :smiley: )\r\n\r\n# Proposed change\r\n\r\nMerge `if`-`then`-`else` (two-way `if`) and multi-way `if`, keeping the best of both. \r\n\r\nThe dreadful:\r\n```elm\r\nif | key == 40 -> n+1\r\n   | key == 38 -> n-1\r\n   | otherwise -> n\r\n```\r\n\r\nBecomes the delightful:\r\n\r\n```elm\r\nif key == 40 then\r\n    n+1\r\nif key == 38 then\r\n    n-1\r\nelse\r\n    n\r\n```\r\n\r\nTwo-way `if`s would remain valid, but now you can easily add extra branches, basically without having to write `else if`. \r\n\r\n(Other syntax options like `->` instead of `then` or leaving off subsequent `if`s can be discussed of course. But this seems the nicest option to me right now. )\r\n\r\n# Motivation\r\n\r\nHaving two constructs like this means there are two ways to do things, which is bad (IMHO, I wish I had a link to some article that argues the same). \r\n\r\nPros of two-way `if`:\r\n\r\n* familiar (more or less, most people haven't seen the `then` before when not familiar with FP)\r\n* exhaustive, `else` branch **has** to be written\r\n* indentation sensitive\r\n\r\nPros of multi-way `if`:\r\n\r\n* multi-way!\r\n* concise\r\n* conditions line up vertically\r\n\r\nCons of multi-way `if`:\r\n\r\n* The `|` bar which is [alien](https://github.com/elm-lang/elm-plans/issues/3#issuecomment-120782368) and [frustrates style guides](https://github.com/elm-lang/elm-plans/issues/3#issuecomment-120948393)\r\n* Not indentation sensitive, which is a bug that leads to it being un-nestable\r\n\r\n# Considerations\r\n\r\n1. The forced else branch is nice for easy exhaustiveness checking (none required). It may frustrate people who would write:\r\n\r\n  ```elm\r\n  if key == 0 then n+1\r\n     key < 0 then n-1\r\n     key > 0 then n\r\n     else Debug.crash \"bloody compiler forces me to write this case that will never be triggered\"\r\n  ```\r\n\r\n  But it's actually a nice feature, because the above can be written without the `Debug.crash` if you make one of those conditional branches the `else` branch, and in some cases [it will point people at a place where a union type could be a better fit](http://stackoverflow.com/a/31397467/859279). \r\n\r\n2. [Removing multi-way if](https://github.com/elm-lang/elm-plans/issues/3) is another way to deal with solving this \"two ways to write `if`s\" situation, but that would mean you're forced to write this kind of stuff:\r\n\r\n    ```elm\r\n  if key == 40 then\r\n      n + 1\r\n  else if key == 38 then\r\n      n - 1\r\n  else\r\n      n\r\n  ```\r\n\r\n  Not dreadful, but could be better. \r\n\r\n3. Now `else` is optional syntax in an `if`-`else`-`if` chain. That's what I'm always against! So I'd really like to enforce the use of this multi-way `if` when chaining `if`s. I think that's reasonable. But I'd like to hear other opinions. "},"comment":{"url":"https://api.github.com/repos/elm-lang/elm-plans/issues/comments/121135849","html_url":"https://github.com/elm-lang/elm-plans/issues/6#issuecomment-121135849","issue_url":"https://api.github.com/repos/elm-lang/elm-plans/issues/6","id":121135849,"user":{"login":"mgold","id":1191970,"avatar_url":"https://avatars.githubusercontent.com/u/1191970?v=3","gravatar_id":"","url":"https://api.github.com/users/mgold","html_url":"https://github.com/mgold","followers_url":"https://api.github.com/users/mgold/followers","following_url":"https://api.github.com/users/mgold/following{/other_user}","gists_url":"https://api.github.com/users/mgold/gists{/gist_id}","starred_url":"https://api.github.com/users/mgold/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mgold/subscriptions","organizations_url":"https://api.github.com/users/mgold/orgs","repos_url":"https://api.github.com/users/mgold/repos","events_url":"https://api.github.com/users/mgold/events{/privacy}","received_events_url":"https://api.github.com/users/mgold/received_events","type":"User","site_admin":false},"created_at":"2015-07-14T05:27:50Z","updated_at":"2015-07-14T05:27:50Z","body":"I am also against optional syntax in theory, but I don't see how you'd disallow the `else`. It's a natural use of the 2-way form, and you can use other proposal's syntax in 0.15. You'd certainly need a good compiler error (\"omit the `else` on all but the last conditional\" or similar).\r\n\r\nSo we go from `if Bool then a else a` to `[if Bool then a]+ else a`."}}