As julia has 1-based arrays, shouldn't enums also be 1-based? Maybe interoperability with C code weights more more important in this case?
x-ref: https://github.com/JuliaLang/julia/pull/10168#issuecomment-75466599
thanks, I see, that this has been discussed extensively, I'll just close this.
You certainly have to question any change that only requires 2 more characters to get the desired behavior:
@Fruit apple banana orange
vs.
@Fruit apple=1 banana orange
the other way round one could argue that it would only take 2 more characters to turn a Julia-consisten (1-based) enum into a C compatible enum (0-based)
@enum Fruit apple banana orange
vs.
@enum Fruit apple=0 banana orange
Why does this alleged form of "consistency" matter?
I don't think it's a big deal.
Why does this alleged form of "consistency" matter?
It might matter if you could have enums acting as array indexes.
I wanted this functionality and created an IntEnums module (rather crude, non-general, non-production).
Perhaps Enums might support this in the future, in which case compatibility with standard array indexing would be better now rather than possibly breaking changes later.
Of course this might be a bit of a stretch.
Julia-0.6.4> @IntEnum Regions north east south west
IntEnum Regions:
north = 1
east = 2
south = 3
west = 4
Julia-0.6.4> sales = zeros(Float64, length(Regions))
4-element Array{Float64,1}:
0.0
0.0
0.0
0.0
Julia-0.6.4> for region in Regions
sales[region] = rand(0:50000)/100
end
Julia-0.6.4> for region in Regions
println(region, " ", sales[region])
end
north 66.19
east 129.88
south 409.46
west 200.81
Most helpful comment
It might matter if you could have enums acting as array indexes.
I wanted this functionality and created an
IntEnumsmodule (rather crude, non-general, non-production).Perhaps
Enumsmight support this in the future, in which case compatibility with standard array indexing would be better now rather than possibly breaking changes later.Of course this might be a bit of a stretch.