Flag for case sensitive in <Type>String(s string) #40

Activity

1. dmarkham commented on Jan 31, 2021

   

   dmarkham

   on Jan 31, 2021

   Owner

   More actions

   yea I knew someone would not be very happy with this change.. If you have a nice patch for a new flag I'm happy to review.
2. dmarkham

   added

   enhancementNew feature or requestNew feature or request

   help wantedExtra attention is neededExtra attention is needed

   on Apr 6, 2021
3. dmarkham commented on Apr 6, 2021

   

   dmarkham

   on Apr 6, 2021

   Last edited by dmarkham

   Owner

   More actions

   I wonder if instead of a flag we just add a new case sensitive method? <Type>SensitiveString(s string) maybe someone has a better name for it.
4. gabe565

   added 3 commits that reference this issue on Oct 11, 2024

   feat: Add `-casesensitive` flag

   ...

   This issue will close once commit fb1078c is merged into the 'master' branch.

   fb1078c

   feat: Add `-casesensitive` flag

   ...

   This issue will close once commit 1e2c502 is merged into the 'master' branch.

   1e2c502

   feat: Move lower-cased names to a separate map to improve case support

   ...

   This issue will close once commit 0ef6832 is merged into the 'master' branch.

   0ef6832
5. gabe565 commented on Oct 11, 2024

   

   gabe565

   on Oct 11, 2024

   Last edited by gabe565

   Contributor

   More actions

   @dmarkham @rucciva This just caused a bug in an app I built, so I decided to propose some fixes. The current behavior causes a silent bug if there are two consts with the same value other than a case change, like here.

   My two ideas to fix are:

   1. Add a -casesensitive flag, which disables all generation of lower-cased values.
      • This required more code changes up front, and users have to know to add the -casesensitive flag, but the resulting functionality completely eliminates the possibility of choosing the incorrect value.
      • This method also has the benefit of not changing existing code after users update enumer. Code would only change after adding -casesensitive.
      • Unfortunately, users may not realize there is a -casesensitive flag and could introduce bugs in their code in the future.
      • See PR feat: Add -casesensitive flag #96
   2. Split _typeNameToValueMap into _typeNameToValueMap and _typeLowerNameToValueMap.
      • _typeNameToValueMap is checked first with a fallback to the lower-cased map. This lets the current case-insensitivity behavior stay the same, while also choosing the correct value if there are overlaps.
      • This route seems like a safer option since users don't need to be aware of a flag, but code will be slightly different after people update enumer. Is that ok?
      • Unfortunately, the golden files will all need to be updated if we go this route. Is there are way to re-generate them? (Used the golden test to regenerate).
      • See PR fix: Move lower-cased names to a separate map to fix overlapping cases #97

   I opened a PR for both of these solutions, but only one needs to be merged...although both being merged might be nice. The first solution would be nice for times where casing should explicitly be respected, while the second prevents a bug without requiring a flag.

   Any thoughts?
6. gabe565

   added a commit that references this issue on Oct 11, 2024

   feat: Move lower-cased names to a separate map to improve case support

   ...

   This issue will close once commit b25a89e is merged into the 'master' branch.

   b25a89e
7. dmarkham commented on Oct 11, 2024

   

   dmarkham

   on Oct 11, 2024

   Owner

   More actions

   @samiam2013 thoughts?
8. gabe565 commented on Oct 11, 2024

   

   gabe565

   on Oct 11, 2024

   Last edited by gabe565

   Contributor

   More actions

   Just want to note that a workaround with the current behavior is to define consts with upper-case values before the lower-cased ones. Here's a quick repro:

   Click to expand...

   package main
   
   import "fmt"
   
   //go:generate enumer -type ExampleLowerFirst -linecomment
   
   type ExampleLowerFirst uint8
   
   const (
   	LFLower ExampleLowerFirst = iota // example
   	LFUpper                          // EXAMPLE
   )
   
   //go:generate enumer -type ExampleUpperFirst -linecomment
   
   type ExampleUpperFirst uint8
   
   const (
   	UFUpper ExampleUpperFirst = iota // EXAMPLE
   	UFLower                          // example
   )
   
   func main() {
   	fmt.Println("ExampleLowerFirst:")
   	var e1 ExampleLowerFirst
   	e1, _ = ExampleLowerFirstString("EXAMPLE")
   	fmt.Println(uint8(e1), e1)
   	e1, _ = ExampleLowerFirstString("example")
   	fmt.Println(uint8(e1), e1)
   
   	fmt.Println("ExampleUpperFirst:")
   	var e2 ExampleUpperFirst
   	e2, _ = ExampleUpperFirstString("EXAMPLE")
   	fmt.Println(uint8(e2), e2)
   	e2, _ = ExampleUpperFirstString("example")
   	fmt.Println(uint8(e2), e2)
   }

   The code above results in:

   ExampleLowerFirst:
   1 EXAMPLE
   1 EXAMPLE
   ExampleUpperFirst:
   0 EXAMPLE
   1 example
   

   Both of my PRs correct this behavior, resulting in:

   ExampleLowerFirst:
   1 EXAMPLE
   0 example
   ExampleUpperFirst:
   0 EXAMPLE
   1 example
   

   The more I think about it, the more I'm preferring the second option since it fixes this bug without any developer intervention, other than re-generating.
9. samiam2013

   self-assigned this

   on Jul 31, 2025
10. samiam2013

    removed their assignment

    on Apr 22, 2026
11. dmarkham

    closed this as completedin #128on Oct 3, 2026
12. dmarkham

    added a commit that references this issue on Oct 3, 2026

    Split exact and lower-cased name lookup into two maps

    ...

    This issue will close once commit a869a9c is merged into the 'master' branch.

    a869a9c