for a in MyEnum gives incorrect results with enum with holes

[timotheecour]

for a in MyEnum gives incorrect results with enum with holes.

Before you say

Yeah, enums with holes are simply madness. We should deprecate them for 1.4.

they still have valid use cases for interop (a necessary evil) and all existing alternatives (const + distinct cint or holyEnum #13980 (comment)) have their own caveats, and in any case, we still need to support them for backward compatibility.

The fix is not hard, it's done by something similar (and simpler!) to the magic iterators.fields.

Example

when true: # D20200416T162309
  type Foo = enum
    f1 = -1, f2 = 13, f3 = 20
  for ai in Foo: echo ai

Current Output

f1
0 (invalid data!)
f2
f3

Expected Output

f1
f2
f3

Possible Solution

• create a magic enumItems similar to iterators.fields

Additional Information

• related to Weird unsafe behaviour with enums with holes #13980
• nim d3b0132 1.3.1

[alaviss]

We can just ban this for enum with holes.

A wide range of operations should be banned for them too (like inc, dec). They aren't ordinals and shouldn't be treated like one.

[Araq]

Precisely what @alaviss said.