Unclear error "Duplicate field index" with enum array.

[Chamberlain91]

Context

Was attempting to use an enum array [E]V and encountered a confusing "duplicate keys" issue when there are no duplicate keys.

Odin:    dev-2025-12:60130b87b
OS:      Windows 11 Home Basic (version: 25H2), build 26200.7462
CPU:     AMD Ryzen 9 9900X 12-Core Processor
RAM:     63109 MiB
Backend: LLVM 20.1.0

Expected Behavior

No error, all keys are unique.

Current Behavior

Error of "Duplicate field index" not indicating which duplicate key.

Failure Information (for bugs)

Seems to be related to an alias enum member and an enum member that is a subset of another members name. Not sure exactly, thought it was a prefix thing when I posted but repro without it.

Edit: Determined to be not a bug, but an improved diagnostic message about which names are duplicated on which value may illuminate the issue more clearly.

Steps to Reproduce

package bug

main :: proc() {}

Key_Array := [Keys]int {
	.Key_0           = 0,
	.Key_1           = 0,
	.Key_1_With_More = 0, // Move this line up and down
	.Key_2           = 0,
}

Keys :: enum {
	Key_0,
	Key_1,
	Key_1_With_More, // This having a prefix of Key_1
	Default = Key_1, // Which has this alias member, causing Key_2 to fail.
	Key_2,           // Or Key_1_With_More, depending on order.
}

or

package bug

main :: proc() {}

Key_Array := [Keys]int {
	.Apple  = 0,
	.Banana = 1,
	.Orange = 2,
	.Tomato = 3, // Error here
}

Keys :: enum {
	Apple,
	Banana,
	Orange,
	Default = Apple,
	Tomato,
}

Failure Logs

C:/Projects/odin-bug/bug.odin(9:3) Error: Duplicate field index .Key_2 for enumerated array literal 
        .Key_2           = 0, 
         ^~~~~~~~~~~~~~~~~~^ 

or

C:/Projects/odin-bug/bug.odin(9:3) Error: Duplicate field index .Tomato for enumerated array literal 
        .Tomato = 3, 
         ^~~~~~~~~^ 

[Barinzaya]

Look at the numeric values of the enum variants. What you're defining are:

Keys :: enum {
	Key_0 = 0,
	Key_1 = 1,
	Key_1_With_More = 2,
	Default = 1,
	Key_2 = 2, // same as Key_1_With_More
}
Keys :: enum {
	Apple = 0,
	Banana = 1,
	Orange = 2,
	Default = 0,
	Tomato = 1, // same as Banana
}

Both of these, indeed, have duplicates. It's the numeric value that's used to index the enumerated array, and your = Default is making some of the variants end up with the same value.

[Chamberlain91]

That makes no sense! The automatic values should not reset to a lower value when an alias is defined.

If this is actually "intended behavior" the error message I'm getting should at least be improved to show the duplicate index value itself so that there's more intuition about this automatic counting.

[Barinzaya]

That's how it works in most languages that I can think of (that have numeric enums). Automatic values are just the previous value + 1 (or 0 for the first one), which means you can do stuff like

Foo :: enum {
  A = 123,
  B, // 124
  C, // 125

  D = 234,
  E, // 235
  F, // 236
}

[Chamberlain91]

Yes! With an explicit value, but with an alias member I did not expect it to change anything since I'm not introducing a new value to the enum.

[Barinzaya]

There's not really a fundamental difference between the two. Either way, you're assigning an explicit value.

It works the same even if the value isn't new:

Foo :: enum {
  A = 123,
  B, // 124
  C, // 125

  D = 123, // = A is the same thing
  E, // 124
  F, // 125
}

It's a very simple "the previous value + 1".

If you don't want to interfere with the automatic numbering, just put your explicit values last.

[Chamberlain91]

Yeah, I see that does match C enum behavior testing it with gcc. I was very confused by this last night, so I guess the "request" here isn't a bug fix but possibly a UX improvement with "Duplicate field index" specifying the duplicate name(s) and value to help clarify that. Should I alter this issue to reflect that, or close it and make another?

[Kelimion]

I think it might indeed be valuable to list out the duplicate names and the conflicting value, so I've tagged it thusly.