Open SimonDanisch opened 8 years ago
@vchuravy
if you have very small and very large values,
membershiptest
will be slow or even throwOutOfMemory
exceptions.
https://github.com/JuliaLang/julia/pull/15660
in c you very often use
enum1 & enum2 == enumx
, this functionality might be wanted inBase
as well
https://github.com/JuliaLang/julia/pull/2988
It'll be nice to not define the show methods on the concrete type directly since otherwise it cannot be easily redefined.
It might be preferable to have an EnumSet{E<:Enum}
type that lets you express sets of values of a given Enum
type E
. The integer values of e ∈ E
would be used to indicate the bit offset for e
in an EnumSet{E}
collection. It seems to me that it makes sense to semantically distinguish between APIs that expect individual enum values and some set of enum values.
Any update on this?
The fact that you cant use the Julia enum to map into C enum is quite annoying when you want to generate a wrapper.
Which of the above points still hold?
For C enums with multiple fields with the same value, I currently get by with just
@enum Fruit apple=1 orange=2
const kiwi = orange
I found a few problems with the current enum implementation:
OutOfMemory
exceptions.@enum
can't be use with Clang to wrap c.enum1 & enum2 == enumx
, this functionality might be wanted in Base as wellenum_values
&enum_names
, which return the sorted list of enums (i initially thought the number of emitted functions are the reason that compilation is so slow)Last point got a bit less interesting after fixing the other points made everything compile fast already. I still wrote a toy implementation of it: https://gist.github.com/SimonDanisch/88f73018d6bf5219574ec1c679bc76ef
What we should at least use from this is:
For the unique values, we should decide if there should be an extra type Cenum, or if we just don't guarantee mappings to correct names if you decide to use multiple fields with the same value.
Best, Simon