Jonathan Lang wrote: > Wouldn't that be C< = 0...* >?
Indeed. Thanks for the correction. > That said, don't we already have a means of assigning specific values > to individual members of an enum? I forget the exact syntax, The exact syntax is: enum Perms [Read => 1, Write => 2, Exec => 4, Fold => 8, Spindle => 16, Mutilate => 32] or enum Perms << :Read(1), :Write(2), :Exec(4), :Fold(8), :Spindle(16), :Mutilate(32) >> or any other variation that uses a list of pairs. > Clumsy, sure; The clumsiness isn't the main problem, in my view; the explicitness of having to provide the values is. Even the hyperoperated version (which isn't currently legal, BTW) requires an explicit series to generate the values. Yet the whole point of enums is to avoid explicitly enumerating the values (as far as possible). The secondary point here is that an enum type doesn't solve the original problem, since it won't allow combinations of enumerated values: enum Perms [Read => 1, Write => 2, Exec => 4, Fold => 8, Spindle => 16, Mutilate => 32]; my Perms $perms = Read +| Write; # Error I'm now strongly convinced that a module is the right answer here. We have the need for a datatype that is essential is a couple of domains, but much better handled via Sets in most other contexts. So it's inherently a special-purpose datatype, and hence not appropriate in the core language. And Perl 6 already provides the macro mechanism needed to allow such a datatype to be seamlessly added with a convenient and "natural" syntax. Which is what I shall eventually do, I suspect. In that sense this discussion *vindicates* the current design, demonstrating that it provides the necessary flexibility and tools to allow someone to implement a new datatype and declarator syntax and integrate them seamlessly into the language, without having to redefine the language itself...or modify the compiler. Damian