3 ms·
I'm assuming he meant why would they expose or promote the use of a construct that bypasses type safety in a statically typed language. Although `interface {}`
by TheHydroImpulse 12y ago
I'm assuming he meant why would they expose or promote the use of a construct that bypasses type safety in a statically typed language. Although `interface {}` is not some sort of special feature, it's still circumventing the type system.
- ominous_prime 12y agoYou 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.