...then it's broken, because the Go compiler, factually, cannot (in general) check or enforce the validity of specific values.
> there's no reason for you to also include runtime checks. Other developers breaking your defined contract is not your responsibility, it's not even a bug.
It is absolutely the responsibility of the function
func PrintColor(c Color)
What strategies do you use in your programs to ensure type safety in the event of debugging, mmap, and other systems that you can use to subvert the memory layouts your compiler thinks it produced?
Most instructions are not atomic, so even if you had runtime checks something like a debugger could still inject invalid state in between your checks, making them ineffective.
If real-time code injection is your threat model, I don't see how runtime checks would get you anywhere.
Can you give an example where someone has done similar casts accidentally? It seems like it would be hard to accidentally typo similar kinds of casts. That leaves malice, which seems difficult to defend against, in light of the kinds of system calls that are available to a program.
I don't doubt that there are niches where such explicit type coercion patterns are common in Go and susceptible to mistakes, but I doubt usage of constant identifiers is such a niche.
Rust is currently the standard bearer for strong, static type safety, and it even has both the enum types and pattern matching construct which Go lacks. AFAIU, you can use unsafe{} Rust code to perform a similar type punning trick, successfully assigning an invalid value to an enum object. I don't know if Rust's code generator always inserts runtime validity checks in match statements on an enum value without a catchall/default case, but certainly it's possible for Rust code to have an explicit if/else chain that at compile time appears comprehensive but which would neither panic nor produce the expected behavior. Does that mean Rust programmers shouldn't rely on Rust's static typing, instead always adding explicit code to handle unknown/invalid enum values?
Maybe the assertion that Go code should have such checks is more reasonable than for Rust code, but you haven't explained how. At least to me, the simplest, minimal code to achieve the subversion in both Go and Rust seems similarly stilted and similarly unlikely to be written by mistake. (To be clear, the context of this subthread as I understand it assumes the interface method hack, the subversion of which requires the type punning.)
If I write a function that takes Foo as an argument. I have a Foo implementation exposed elsewhere in my program. It is absolutely expected that I mean MY Foo, not your Foo. If you pass me your Foo, you will get unexpected results that are not a bug, not a side effect, not my responsibility. It’s yours, the caller, to adhere to the contract.
There are valid reasons to not adhere. To pass your own implementation. At that point, you are responsible for its use. Not me. If it adheres to MY Foo’s interface, you might get by, but it’s is not my responsibility to validate all permutations of unknown types to ensure you’re passing me mine. In go, it’s perfectly valid to return structs but accept interfaces as arguments so that you, the program author calling my api, can craft the correct program flow.
So please, leave that runtime type check reflection for Java and C# and the land of JS. We have no need for it here in machine code land.
Of course it is! If you provide an API that takes a Color, and you define valid Colors as exclusively Red, Green, and Blue, then you are absolutely responsible for validating input Color values and rejecting anything which is not Red, Green, or Blue. If you delegate that responsibility to the caller, then your API provides no meaningful encapsulation, and isn't a useful abstraction -- it's entirely leaky. No bueno.
(That said, the Go syntax looks far less "scary" than `unsafe { transmute::<_, Colour>("orange") }`, which I'd definitely call a design issue.)
Likewise GLint is just a type alias for int. There are only value types (str, int, float, etc), everything else is a construct. The only true types are those value types (and pointers to them). If you call a type a Color and I call a type a Color, you are using my lib to build a program (not me using yours), you must adhere to my contract of what a Color type is to my API. Period. You can not call a function with an unknown type and expect it to behave properly.
If it panics, it’s your fault.
c = Color("orange") does not compile.
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.
If we're talking compile-time, then: yes, absolutely!
Type hinting doesn't provide type safety, because type safety isn't a spectrum.
Is "type safety" something you saw defined in a PL book or something, which has a more rigid definition to you?
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.
Casting is by definition an escape hatch.
c := color.Red
c = Color("orange")
PrintColor(c)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 ColorIn Go, they are not. Aliases establish precise equivalence between types, type redefinitions establish new types altogether.
package color
type Color interface {
void()
}
type color struct {
v string
}
func (c color) void() {}
func (c color) String() string {
return c.v
}
var (
Red color = color{"red"}
Green color = color{"green"}
Blue color = color{"blue"}
) func fn(c color.Color) {
switch c {
case color.Red, color.Green, color.Blue:
log.Printf("c=%#+v -- OK", c)
default:
log.Printf("c=%#+v -- should not be possible", c)
}
}
func main() {
var c color.Color
fn(c)
}
c=<nil> -- should not be possible