{"action":"created","issue":{"url":"https://api.github.com/repos/executors/executors/issues/347","repository_url":"https://api.github.com/repos/executors/executors","labels_url":"https://api.github.com/repos/executors/executors/issues/347/labels{/name}","comments_url":"https://api.github.com/repos/executors/executors/issues/347/comments","events_url":"https://api.github.com/repos/executors/executors/issues/347/events","html_url":"https://github.com/executors/executors/issues/347","id":296830762,"number":347,"title":"Mutually-exclusive properties cleanup idea","user":{"login":"jaredhoberock","id":1253007,"avatar_url":"https://avatars2.githubusercontent.com/u/1253007?v=4","gravatar_id":"","url":"https://api.github.com/users/jaredhoberock","html_url":"https://github.com/jaredhoberock","followers_url":"https://api.github.com/users/jaredhoberock/followers","following_url":"https://api.github.com/users/jaredhoberock/following{/other_user}","gists_url":"https://api.github.com/users/jaredhoberock/gists{/gist_id}","starred_url":"https://api.github.com/users/jaredhoberock/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jaredhoberock/subscriptions","organizations_url":"https://api.github.com/users/jaredhoberock/orgs","repos_url":"https://api.github.com/users/jaredhoberock/repos","events_url":"https://api.github.com/users/jaredhoberock/events{/privacy}","received_events_url":"https://api.github.com/users/jaredhoberock/received_events","type":"User","site_admin":false},"labels":[{"id":426617226,"url":"https://api.github.com/repos/executors/executors/labels/enhancement","name":"enhancement","color":"84b6eb","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-02-13T17:56:57Z","updated_at":"2018-02-13T20:04:47Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"In various places in P0443R5, we say that certain sets of properties are mutually-exclusive. I would like to find a way to use the C++ type system to enforce these requirements and remove such statements. If we can do so, we should be able to completely eliminate the possibility of an executor author accidentally implementing `.query(always_blocking_t) == .query(never_blocking_t)` and similar bugs.\r\n\r\nMy basic idea is to make sets of properties such as `possibly_blocking`, `always_blocking`, and `never_blocking` instances of the same underlying `blocking_t` type with differing values:\r\n\r\n```\r\nconstexpr blocking_t blocking{};\r\nconstexpr blocking_t possibly_blocking{blocking_t::possibly};\r\nconstexpr blocking_t always_blocking{blocking_t::always};\r\nconstexpr blocking_t never_blocking{blocking_t::never};\r\n```\r\n\r\n#### Blocking properties\r\n\r\n    class blocking_t\r\n    {\r\n      public:\r\n        enum guarantee {possibly, always, never};\r\n  \r\n        static constexpr bool is_requirable = false;\r\n        static constexpr bool is_preferable = false;\r\n  \r\n        using polymorphic_query_result_type = guarantee;\r\n  \r\n        template<class Executor>\r\n          static constexpr bool static_query_v\r\n            = Executor::query(blocking_t());\r\n  \r\n      constexpr guarantee value() const { return guarantee_; }\r\n\r\n      private:\r\n        guarantee guarantee_; // exposition only\r\n    };\r\n\r\nAn advantage of this approach is that it would reduce the number of `.query()` overloads executors need to implement. Instead of implementing three different overloads for the blocking properties, only one would be needed.\r\n\r\nDoes this make sense, and if so, is it compatible with P0443R5's properties design?"},"comment":{"url":"https://api.github.com/repos/executors/executors/issues/comments/365387260","html_url":"https://github.com/executors/executors/issues/347#issuecomment-365387260","issue_url":"https://api.github.com/repos/executors/executors/issues/347","id":365387260,"user":{"login":"jaredhoberock","id":1253007,"avatar_url":"https://avatars2.githubusercontent.com/u/1253007?v=4","gravatar_id":"","url":"https://api.github.com/users/jaredhoberock","html_url":"https://github.com/jaredhoberock","followers_url":"https://api.github.com/users/jaredhoberock/followers","following_url":"https://api.github.com/users/jaredhoberock/following{/other_user}","gists_url":"https://api.github.com/users/jaredhoberock/gists{/gist_id}","starred_url":"https://api.github.com/users/jaredhoberock/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jaredhoberock/subscriptions","organizations_url":"https://api.github.com/users/jaredhoberock/orgs","repos_url":"https://api.github.com/users/jaredhoberock/repos","events_url":"https://api.github.com/users/jaredhoberock/events{/privacy}","received_events_url":"https://api.github.com/users/jaredhoberock/received_events","type":"User","site_admin":false},"created_at":"2018-02-13T20:04:47Z","updated_at":"2018-02-13T20:04:47Z","author_association":"CONTRIBUTOR","body":"Think there may be a problem with such a scheme's interaction with `require()`.\r\n\r\nWe'd want to allow `ex.require(always_blocking)`, `ex.require(never_blocking)`, and `ex.require(possibly_blocking)` to return different types of executors. I don't see a way to do that with this approach."}}
{"actor":{"display_login":"jaredhoberock"}}