4 ms·
You don't lose "type safety", as interfaces retain all type information -- you're not casting `void*` pointers (without the unsafe package), and type conversion
by ominous_prime 12y ago
You don't lose "type safety", as interfaces retain all type information -- you're not casting `void*` pointers (without the unsafe package), and type conversions are limited and well defined.
It however does pass the type checking to run-time instead of compile-time, which is a trade-off that some feel is worth the language simplicity.
- TheHydroImpulse 12y ago> It however does pass the type checking to run-time instead of compile-time That's absolutely still loosing type safety. Reflections don't substitute type safety.
- ominous_prime 12y agoNo, it's still type safe (http://en.wikipedia.org/wiki/Type_safety http://en.wikipedia.org/wiki/Type_safety), memory safe, and free of undefined behavior. There's is no way to use a type contained in an interface as the incorrect type (without the unsafe package, but that wouldn't need an interface anyway), or to inadvertently access or modify arbitrary memory. I also wouldn't consider Go type assertions to be in the same class as reflection. A type assertion is the way you extract and check the underlying type from an interface, and is quite common even when using more complex interfaces. There's also no way to make use of the underlying type from an interface without first asserting it as that type.
- TheHydroImpulse 12y agoType assertions happen during runtime, thus using reflections. There is no other way than to use reflections.