1. 23
    1. 5

      But, now that you’ve exported FlagID I can create my own, which you aren’t handling:


      1. 11

        Do you mean FlagID{…}? You can’t do that since the field is unexported.

        The only value you can construct from outside the package is the zero value FlagID{}. This is not ideal, but if the enum has a reasonable default value, you can interpret it as that default and special case it in the String method.

        1. 2

          Oh damn, you are right! I can’t believe I missed that!

    2. 1

      Never realized that global can’t be constants. Is there a simple reason for that I’m missing?

      1. 1

        I honestly don’t know what they mean, you can export constants, and you can have package level constants. Is there some global scope above that which can only be variable and not constant?

        1. 2

          In the two common ways to do enums that he mentions, the custom types used for FlagID are just strings and ints, which can be constants, but in the new way he’s suggesting making FlagID a struct type, which cannot be a constant. This means your global/package-level enums can be overwritten by whatever code imports your package, whereas the “common” ways are using constants which can’t be overwritten.

          1. 1

            Right, I knew that there were numeric and string contants, and that more complex types (structs, etc) couldn’t be constants. Rereading the paragraph in the article, I had misinterpreted it the first time as stating that any global thing had to be variable, which is obviously wrong. Hence my confusion.