Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compile-time safety for enumerations in Go

vladimir.varank.in

Post reply on HN
Print view View original

21–30 of 116 posts

Re: Compile-time safety for enumerations in Go

#21

Post by throwaway894345 »

kiitos wrote: post #19

Unfortunately not. func main() { c := color.Red cptr := (*string)(&c) *cptr = "orange" PrintColor(c) // successfully compiles, and prints "orange" }

You're not changing the underlying value of `color.Red`, you're changing the variable (in other words, `PrintColor(color.Red)` will still print `red`). If that's the point you're intending to make, then couldn't you make it more easily with this?:

    c := color.Red
    c = Color("orange")
    PrintColor(c)

Re: Compile-time safety for enumerations in Go

#22

Post by throwaway894345 »

revoly wrote: post #20
kiitos wrote: post #19

Unfortunately not. func main() { c := color.Red cptr := (*string)(&c) *cptr = "orange" PrintColor(c) // successfully compiles, and prints "orange" }

I don't think the solution is trying to cover this. If a user does type conversion then usually they know what they are doing. It's like going out of the way. The solution is to just hide a type behind an interface to be explicit about it and to avoid the error that would have gone unnoticed otherwise.

The type conversion is a red herring. He's just changing the value of a variable by referencing and dereferencing a pointer. In other words, he's not using a pointer conversion to change the value of `color.Red`, he's creating a new variable `c` and assigning `color.Red` to it, and then changing the value of the variable through the pointer and type conversion. But he doesn't even need to do the pointer/type conversion stuff, he could just do `c = Color("orange")` and call it a day.

Re: Compile-time safety for enumerations in Go

#24

Post by masklinn »

throwaway894345 wrote: post #21
kiitos wrote: post #19

Unfortunately not. func main() { c := color.Red cptr := (*string)(&c) *cptr = "orange" PrintColor(c) // successfully compiles, and prints "orange" }

You're not changing the underlying value of `color.Red`, you're changing the variable (in other words, `PrintColor(color.Red)` will still print `red`). If that's the point you're intending to make, then couldn't you make it more easily with this?: c := color.Red c = Color("orange") PrintColor(c)

> You're not changing the underlying value of `color.Red`

Doesn't matter, the point is they're getting in a value which is not part of the defined set, demonstrating that this emulation is not actually typed-safe.

> If that's the point you're intending to make, then couldn't you make it more easily with this?:

    cannot convert "orange" (untyped string constant) to type Color

Re: Compile-time safety for enumerations in Go

#27

Post by kiitos »

throwaway894345 wrote: post #22
revoly wrote: post #20

Earlier quoted context omitted.

I don't think the solution is trying to cover this. If a user does type conversion then usually they know what they are doing. It's like going out of the way. The solution is to just hide a type behind an interface to be explicit about it and to avoid the error that would have gone unnoticed otherwise.

The type conversion is a red herring. He's just changing the value of a variable by referencing and dereferencing a pointer. In other words, he's not using a pointer conversion to change the value of `color.Red`, he's creating a new variable `c` and assigning `color.Red` to it, and then changing the value of the variable through the pointer and type conversion. But he doesn't even need to do the pointer/type conversi…

> But he doesn't even need to do the pointer/type conversion stuff, he could just do `c = Color("orange")` and call it a day.

c = Color("orange") does not compile.

Re: Compile-time safety for enumerations in Go

#28

Post by kiitos »

tedunangst wrote: post #25
kiitos wrote: post #19

Unfortunately not. func main() { c := color.Red cptr := (*string)(&c) *cptr = "orange" PrintColor(c) // successfully compiles, and prints "orange" }

At some point I think it's worth asking who are we trying to stop and why.

Indeed. Go types are like simple locks: they keep honest users honest, but they don't prevent dishonest users from breaking your assumptions. The point is just that "compile-time type safety for enumerations" isn't actually true, or even possible. You always have to do some amount of runtime validation of received values.

Re: Compile-time safety for enumerations in Go

#29

Post by kiitos »

revoly wrote: post #20
kiitos wrote: post #19

Unfortunately not. func main() { c := color.Red cptr := (*string)(&c) *cptr = "orange" PrintColor(c) // successfully compiles, and prints "orange" }

I don't think the solution is trying to cover this. If a user does type conversion then usually they know what they are doing. It's like going out of the way. The solution is to just hide a type behind an interface to be explicit about it and to avoid the error that would have gone unnoticed otherwise.

The article is titled "Compile-time safety for enumerations in Go" but my example demonstrates that this is not the case.

Re: Compile-time safety for enumerations in Go

#30

Post by taeric »

kiitos wrote: post #29
revoly wrote: post #20

Earlier quoted context omitted.

I don't think the solution is trying to cover this. If a user does type conversion then usually they know what they are doing. It's like going out of the way. The solution is to just hide a type behind an interface to be explicit about it and to avoid the error that would have gone unnoticed otherwise.

The article is titled "Compile-time safety for enumerations in Go" but my example demonstrates that this is not the case.

The counter point is that this is like arguing that an article about safe knife skills are silly, because you can still just stab yourself?
Post reply on HN