{"action":"created","issue":{"url":"https://api.github.com/repos/ldionne/hana/issues/23","labels_url":"https://api.github.com/repos/ldionne/hana/issues/23/labels{/name}","comments_url":"https://api.github.com/repos/ldionne/hana/issues/23/comments","events_url":"https://api.github.com/repos/ldionne/hana/issues/23/events","html_url":"https://github.com/ldionne/hana/issues/23","id":63550623,"number":23,"title":"Should enumerations be Enumerable?","user":{"login":"ldionne","id":700834,"avatar_url":"https://avatars.githubusercontent.com/u/700834?v=3","gravatar_id":"","url":"https://api.github.com/users/ldionne","html_url":"https://github.com/ldionne","followers_url":"https://api.github.com/users/ldionne/followers","following_url":"https://api.github.com/users/ldionne/following{/other_user}","gists_url":"https://api.github.com/users/ldionne/gists{/gist_id}","starred_url":"https://api.github.com/users/ldionne/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ldionne/subscriptions","organizations_url":"https://api.github.com/users/ldionne/orgs","repos_url":"https://api.github.com/users/ldionne/repos","events_url":"https://api.github.com/users/ldionne/events{/privacy}","received_events_url":"https://api.github.com/users/ldionne/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/ldionne/hana/labels/feature","name":"feature","color":"207de5"},{"url":"https://api.github.com/repos/ldionne/hana/labels/help%20wanted","name":"help wanted","color":"159818"},{"url":"https://api.github.com/repos/ldionne/hana/labels/question","name":"question","color":"cc317c"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-03-22T16:31:52Z","updated_at":"2015-09-13T09:48:13Z","closed_at":"2015-09-13T01:16:32Z","body":"This was triggered a while ago by a discussion on the [Boost.Devel](http://thread.gmane.org/gmane.comp.lib.boost.devel/255045) mailing list. We could provide a macro allowing an enumeration to be defined, while at the same time giving it a model of the `Enumerable` concept. I'll consider adding this if enough people want it.\r\n"},"comment":{"url":"https://api.github.com/repos/ldionne/hana/issues/comments/139857146","html_url":"https://github.com/ldionne/hana/issues/23#issuecomment-139857146","issue_url":"https://api.github.com/repos/ldionne/hana/issues/23","id":139857146,"user":{"login":"m-j-w","id":14040010,"avatar_url":"https://avatars.githubusercontent.com/u/14040010?v=3","gravatar_id":"","url":"https://api.github.com/users/m-j-w","html_url":"https://github.com/m-j-w","followers_url":"https://api.github.com/users/m-j-w/followers","following_url":"https://api.github.com/users/m-j-w/following{/other_user}","gists_url":"https://api.github.com/users/m-j-w/gists{/gist_id}","starred_url":"https://api.github.com/users/m-j-w/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/m-j-w/subscriptions","organizations_url":"https://api.github.com/users/m-j-w/orgs","repos_url":"https://api.github.com/users/m-j-w/repos","events_url":"https://api.github.com/users/m-j-w/events{/privacy}","received_events_url":"https://api.github.com/users/m-j-w/received_events","type":"User","site_admin":false},"created_at":"2015-09-13T09:48:13Z","updated_at":"2015-09-13T09:48:13Z","body":"Louis, I should take the opposition on that, not necessarily on the removal of the concept, but the removal of `succ` and `pred`, for simple reason: When working with values and generic algorithms, you would want to get the next and previous possible value of a data type, like in a simple for loop where you do a `for (int i = 0; i < 10; ++i) {}`. Removing them seems like removing value-based algorithm capability and restricting the library to index-based algorithms. \r\n\r\nAs such, I would in fact propose the opposite direction of this commit, taking the point of your commit message into account: Re-introduce an `inc` and `dec` method, provide a general overload to `operator++` and `operator--`, and add a `max_val` and `min_val` to the datatype to define bounds. That way you would have implicitely defined an interval, stride etc.\r\n\r\nOne might argue, that `operator++` simply is `plus(v, one(v))`, but `one` is not necessarily the same value. Suppose a user wants to implement generic `stride`s, like over even numbers as an extension to `range`, then `inc` and `dec` would equal 2, still with unit 1 to fulfil the laws of the ring.\r\n\r\nThat would then give you the opportunity to `for (myT i = zero(myT()); i < max_val(myT()); ++i)`, for some type that has been somehow modified during compile-time to fit your actual run-time needs - a purpose I would assume to be quite common, as in iterate over all possible values and check whether they are included in a run-time sequence. Whether that defines a concept of an `Enumerable` or simply extends `Iterable` or something like `Value_Iterable`, I don't know. Perhaps `Incrementable` would suit best.\r\n\r\nBesides, I would in fact vote for `inc` and `dec` to remove ambiguity. I read `pred` always as shorthand for predicate, like it is frequently used as template parameter, and am I bit irritated."}}