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

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?


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?


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.




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

Search: