{"action":"created","issue":{"url":"https://api.github.com/repos/nim-lang/Nim/issues/8465","repository_url":"https://api.github.com/repos/nim-lang/Nim","labels_url":"https://api.github.com/repos/nim-lang/Nim/issues/8465/labels{/name}","comments_url":"https://api.github.com/repos/nim-lang/Nim/issues/8465/comments","events_url":"https://api.github.com/repos/nim-lang/Nim/issues/8465/events","html_url":"https://github.com/nim-lang/Nim/issues/8465","id":345232732,"node_id":"MDU6SXNzdWUzNDUyMzI3MzI=","number":8465,"title":"RFC: unified quasi-bool handling","user":{"login":"Bulat-Ziganshin","id":1798016,"node_id":"MDQ6VXNlcjE3OTgwMTY=","avatar_url":"https://avatars1.githubusercontent.com/u/1798016?v=4","gravatar_id":"","url":"https://api.github.com/users/Bulat-Ziganshin","html_url":"https://github.com/Bulat-Ziganshin","followers_url":"https://api.github.com/users/Bulat-Ziganshin/followers","following_url":"https://api.github.com/users/Bulat-Ziganshin/following{/other_user}","gists_url":"https://api.github.com/users/Bulat-Ziganshin/gists{/gist_id}","starred_url":"https://api.github.com/users/Bulat-Ziganshin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Bulat-Ziganshin/subscriptions","organizations_url":"https://api.github.com/users/Bulat-Ziganshin/orgs","repos_url":"https://api.github.com/users/Bulat-Ziganshin/repos","events_url":"https://api.github.com/users/Bulat-Ziganshin/events{/privacy}","received_events_url":"https://api.github.com/users/Bulat-Ziganshin/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-07-27T13:47:34Z","updated_at":"2018-07-27T14:57:53Z","closed_at":null,"author_association":"NONE","body":"We have several PRs (#8358 #8369 #8366) made by @krux02 and @PMunch proposing short-circuit evaluation schemes for Option[T] and other types.\r\n\r\nThis eventually can lead to zoo of incompatible decisions and once again make the language irregular and thus harder to learn. I can propose two ways to make this feature more orthogonal:\r\n\r\n### Approach#1 - implement it in generic way:\r\n\r\nEach type T that declares itself as quasi-bool should implement `toBool(x:T): bool`.\r\n\r\n```Nim\r\nproc `or`[T](x,y:T): T = \r\n    if toBool(x): x; else: y\r\n\r\nproc find_first_nonempty[T] (c: Container[T]): Option[T] = \r\n    for x in c:\r\n        if toBool(x):\r\n            return Some(x)\r\n...\r\n```\r\n\r\nThis allows us to define a lot of operations in generic way, define hasToBool concept, and optionally - redefine if/while/... to accept quasi-bools as conditions. Eventually, by defining the single toBool operation, a type will get access to plenty of operations, including ones defined in application code. \r\n\r\nAnd users will need to learn these operations only once and then can apply them to any type with \"nil value\" concept instead of learning new set of operations for every new type.\r\n\r\nIn particular, I will be glad if we will copy Haskell operation names on Maybes :)\r\n\r\n \r\n### Approach#2 - define guidelines\r\n\r\nJust define guidelines - what extended 'or' and other ex-bool operations should do, and what they cannot do. Go with ad-hoc definitions. And may be later change it to the first approach."},"comment":{"url":"https://api.github.com/repos/nim-lang/Nim/issues/comments/408444456","html_url":"https://github.com/nim-lang/Nim/issues/8465#issuecomment-408444456","issue_url":"https://api.github.com/repos/nim-lang/Nim/issues/8465","id":408444456,"node_id":"MDEyOklzc3VlQ29tbWVudDQwODQ0NDQ1Ng==","user":{"login":"Bulat-Ziganshin","id":1798016,"node_id":"MDQ6VXNlcjE3OTgwMTY=","avatar_url":"https://avatars1.githubusercontent.com/u/1798016?v=4","gravatar_id":"","url":"https://api.github.com/users/Bulat-Ziganshin","html_url":"https://github.com/Bulat-Ziganshin","followers_url":"https://api.github.com/users/Bulat-Ziganshin/followers","following_url":"https://api.github.com/users/Bulat-Ziganshin/following{/other_user}","gists_url":"https://api.github.com/users/Bulat-Ziganshin/gists{/gist_id}","starred_url":"https://api.github.com/users/Bulat-Ziganshin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Bulat-Ziganshin/subscriptions","organizations_url":"https://api.github.com/users/Bulat-Ziganshin/orgs","repos_url":"https://api.github.com/users/Bulat-Ziganshin/repos","events_url":"https://api.github.com/users/Bulat-Ziganshin/events{/privacy}","received_events_url":"https://api.github.com/users/Bulat-Ziganshin/received_events","type":"User","site_admin":false},"created_at":"2018-07-27T14:57:52Z","updated_at":"2018-07-27T14:57:52Z","author_association":"NONE","body":"I just learned that `or` is already defined in Nim as bitwise operation for integer types. It's really hard to build on such unregular base :)\r\n\r\nSo, I feel that it may be better to leave the first approach for its own set of operations such as '&&' or andThen. It's just too late to make generic definition for and/or since they support multiple usecases - boolean ops, bitwise ops and now we may add quasi-boolean ops.\r\n\r\nOTOH, as far as you don't pretend to have toBool(BigInt), defining generic `'or'[T: hasToBool](x,y:T)` is still possible without contradicting to your definitions."}}
{"actor":{"display_login":"Bulat-Ziganshin"}}