Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> No, it isn't, unlike C, in which it is.

Go on. Given:

    type E int
    const (
        A E = iota
        B
        C
    )

    enum E {
        A,
        B,
        C
    }
What is missing in the first case that wouldn't allow you to perform such static analysis? It has a keyword to identify initialization of an enumerated set (iota), it has an associated type (E) to identify what the enum values are applied to, and it has rules for defining the remaining items in the enumerated set (each subsequent constant inherits the next enum element).

That's all C gives you. It provides nothing more. They are exactly the same (syntax aside).

> It warns you

Warnings are not fatal. It compiles just fine. The Go compiler doesn't give warnings of any sort, so naturally it won't do such analysis. But, again, you can use static analysis tools to the same effect. You are probably already using other static analysis tools as there are many other things that are even more useful to be warned about, so why not here as well?

> enum in C carries with it type information.

Just as they do in Go. That's not a property of enums in and of themselves, but there is, indeed, an associated type in both cases. Of course there is. There has to be.



> What is missing in the first case that wouldn't allow you to perform such static analysis?

Type information. The only type info the compiler has is "integer".

> It has a keyword to identify initialization of an enumerated set (iota),

That's not a type.

> it has an associated type (E)

It still only has the one piece of type information, namely "integer".

> and it has rules for defining the remaining items in the enumerated set

That's not type information

> That's all C gives you.

No. C enums have additional information, namely, which other integers that type is compatible with. The compiler can tell the difference between `enum daysOfWeek` and `enum monthsOfYear`.

Go doesn't store this difference - `Monday` is no different in type than `January`.

> Warnings are not fatal.

Maybe, but the warning tells you that they types are not compatible. The fact that the compiler tells you that the types are not compatible means that the compiler knows that the types are not compatible, which means that the compiler regards each of those types as separate types.

Of course you can redirect the warning to /dev/null with a flag, but that doesn't make the fact that the compiler considers them to be different types go away.

Whether you like it or not, C compilers can tell the difference between `Monday` and `January` enums. Go can't tell the difference between `Monday` and `January` constants. How can it?


> That's not a type.

Nobody said it was. Reaching already? As before, enums are not a type, they are a numbering mechanism. Literally. There is an associated type in which to hold the numbers, but that's not the enum itself. This is true in both C and Go, along with every other language with enums under the sun.

> The compiler can tell the difference between `enum daysOfWeek` and `enum monthsOfYear`.

Sure, just as in Go:

    type Day int
    const (
        Monday Day = iota
        Tuesday
        // ...
    )

    type Month int
    const (
        January Month = iota
        February
        // ...
    )

    func month(m Month) {}
    func main() {
        month(January) // OK
        month(Monday)  // Compiler error
    }

> Go doesn't store this difference - `Monday` is no different in type than `January`.

Are you, perhaps, mixing up Go with Javascript?

> How can it?

By, uh, using its type system...? A novel concept, I know.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: