Not sure exactly how or where the functionality would need to be built, but I'd really like to be able to use enums as type parameters. Since we know the definition will be an immutable wrapping a single Cint value, there isn't a difference between using a simple Int, but it would be great to be able to dispatch on different enum values if desired.
The main use-case I have in mind are Timezones for DateTime stuff. All you really want to do is define a big enum with all the different timezones from the olsen database and then use the timezone parameter for a DateTime to lookup the value when computing the offset from +00:00. This allows your DateTime type to maintain a single 64-bit internal representation while allowing an optional timezone parameter as a type tag in later computations. This would totally solve this case where I want to use a type parameter, but not just a regular Int (to restrict values), and not have to use a an empty DateType definition of a timezone as the parameter tag (which I learned does severe "thrashing" of the compiler). -Jacob On Wed, Feb 19, 2014 at 11:52 AM, Stefan Karpinski <[email protected]>wrote: > Yeah, I pretty much agree with all of this. Once field access is > overloadable, we can just create a Direction type and define > (automatically) the following methods: > > getfield(::Type{Direction}, ::Field{:NORTH}) = Direction(0) > getfield(::Type{Direction}, ::Field{:EAST}) = Direction(1) > getfield(::Type{Direction}, ::Field{:WEST}) = Direction(2) > getfield(::Type{Direction}, ::Field{:SOUTH}) = Direction(3) > > > That would make Direction simultaneously a type and let it act like a > "namespace" in the sense that you can do Direction.NORTH and get the value > Direction(0). The definition of the type would be something like this: > > immutable Direction > value::Cint > end > > > So that the values are completely memory compatible with C enums. Not sure > if we need a new keyword for this - especially considering that we'll want > something very similar for flags - i.e. enums where the values are powers > of two. Having @enum and @flag macros may well be enough. But this > definitely needs the ability to overload field access to make it work > completely naturally. > > > On Wed, Feb 19, 2014 at 3:17 AM, Tobias Knopp <[email protected] > > wrote: > >> Yes it would be nice if it would be its own type and if we would have an >> abstract type "Enum" that the concrete enums subclass from. An enum should >> be further >> compatible with Cint and not only through conversions but also when be >> used as field type (to ensure compatibility with C structs). >> >> I further think that it would be worth introducing the "enum" keyword: >> >> enum Direction >> NORTH = 0 >> EAST = 1 >> WEST = 2 >> SOUTH = 3 >> end >> >> But unfortunatly I have zero scheme/parser knowledge so that I can't come >> up with a PR. Still IMHO its important to get a decision on enums rather >> quickly as they >> are needed and actually used in packages (e.g. in Gtk.jl). >> >> >
