E01050: are duplicated values (or are too similar, likely to be confusing)

What went wrong

Two enumeration values are either identical or too similar after normalization. EK9 normalizes enumeration names to detect confusing duplicates.

Worked examples

Compilable examples demonstrating this error and the correct fix:

• ek9 -q 99 (How do I create an enumeration in EK9?)
• ek9 -q 100 (How do EK9 enumerations differ from Java enums?)

Normalization rules

EK9 normalizes by: UPPERCASING + REMOVING UNDERSCORES

These pairs would conflict:

VALUE_1  and  value_1   -> Both normalize to VALUE1
VALUE1   and  value_1   -> Both normalize to VALUE1
MyValue  and  MY_VALUE  -> Both normalize to MYVALUE
Hearts   and  HEARTS    -> Both normalize to HEARTS

How to fix it

• Use clearly distinct enumeration names
• Adopt a consistent naming style (all UPPERCASE or all CamelCase)
• Avoid names that differ only by case or underscores

Rationale

In switch statements, similar names cause ambiguity: with both 'Hearts' and 'HEARTS' declared, a reader of 'case Hearts' cannot tell which value was meant, or whether a 'case HEARTS' beside it is a duplicate.

See also

• E01050: Duplicate/similar values in enum DEFINITION
• E02060: Duplicate values in switch CASE clauses

Examples

Every example is compiled by the EK9 compiler: the first fails exactly as captioned, the others fix it.

Fails with E01050: are duplicated values (or are too similar, likely to be confusing)

#!ek9
defines module error.e01050.bad

  //Deliberately add in Hearts twice
  defines type

    CardSuit as
      Hearts
      Diamonds
      Clubs
      Spades
      Hearts

Fixed: Each enumerated value once, and no two that differ only in case

#!ek9
defines module error.e01050.good

  defines type

    CardSuit
      Hearts
      Diamonds
      Clubs
      Spades

Questions and answers

These Q&A entries show E01050 and its fix:

• Q99: How do I create an enumeration in EK9?
• Q100: How do EK9 enumerations differ from Java enums?