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.

> 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.

Ah, I misunderstood what type color.Red had. My mistake.

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?

I'm not sure how that's comparable. Compile-time type safety is a boolean thing, you either have it or you don't. If you have it, then my example shouldn't compile. But it does compile, so you don't have it.

I think by insisting to view it only as a boolean thing is very limiting. By that measure, are the type safety hints of Python not really giving any type safety? Just give up and go home, as it were? :D

I'm sympathetic to the points, I think. But I also don't have a problem with someone pushing for some type safety as long as you avoid actively trying to go against it.

> By that measure, are the type safety hints of Python not really giving any type safety?

If we're talking compile-time, then: yes, absolutely!

Type hinting doesn't provide type safety, because type safety isn't a spectrum.

To me it's pretty clear that safety is a spectrum (e.g. we give cars safety ratings), and therefore so is type safety.

Is "type safety" something you saw defined in a PL book or something, which has a more rigid definition to you?

Out of 10 possible errors a compiler can catch 0, 1, 2, 3, etc. up to 10.

A compiler that catches 7 errors is more safe than one that catches 4, and one that catches 4 is more safe than one that catches 0.

You demonstrated that you can deliberately circumvent it.

It is the case under certain conditions.

Casting is by definition an escape hatch.

Casting (in the way I did it in my example) is entirely normal and common and in no way an escape hatch.

Ask yourself: what does casting do?