2 ms·

> such as wasting memory Granted, but I'll happily trade a few bytes of stack for zero allocs in many cases. > rather than benefiting from overlapping storage

by weberc2 10y ago

> such as wasting memory Granted, but I'll happily trade a few bytes of stack for zero allocs in many cases. > rather than benefiting from overlapping storage ala Rust enums or C tagged unions Of course, but we don't have those in Go, do we? > as well as losing type safety Tagged structs are not meaningfully less type safe than interfaces. > one has to manually remember which (groups of) fields correspond to which tag values Use an enum for the tag: https://play.golang.org/p/LI2Bh231W3 https://play.golang.org/p/LI2Bh231W3

Manishearth 10y ago
> Tagged structs are not meaningfully less type safe than interfaces. Of course they are. What if you read from or write to the wrong field? > Use an enum for the tag Your example has one contained type per variant. In Rust it is common to have an enum like enum Foo { Variant1(String, u8, Vec<u8>), Variant2(u8), Variant3(String), Variant4(f32), Variant6(f32) Variant5(bool, bool, String) } Naming tags for something like this would be hard. Some of the fields would be shared between variants. Some would not.
- weberc2 10y ago
  > Of course they are. What if you read from or write to the wrong field? This falls under the rubric of "not meaningfully less type safe". This data structure is central in a large project of mine, and I have maybe 3 places where I switch on the type flag. I'm not proposing this as a general purpose replacement for interfaces, only a useful way to abstract over a few known types when you can't afford all of the allocs. > Your example has one contained type per variant. In Rust it is common to have an enum like enum Foo { Variant1(String, u8, Vec<u8>), Variant2(u8), Variant3(String), Variant4(f32), Variant6(f32) Variant5(bool, bool, String) } I agree. I don't propose this as a general purpose replacement for Rust's enums.
  - Manishearth 10y ago
    > I agree. I don't propose this as a general purpose replacement for Rust's enums. Yeah, that's the thing, Rust enums used this way are very powerful. I'm fine with making tagged structy things in cases like the one mentioned, I feel Go can handle that. I'm missing out on all the useful stuff I can do with proper algebraic datatypes.

by weberc2 10y ago

Manishearth 10y ago

> Tagged structs are not meaningfully less type safe than interfaces. Of course they are. What if you read from or write to the wrong field? > Use an enum for the tag Your example has one contained type per variant. In Rust it is common to have an enum like enum Foo { Variant1(String, u8, Vec<u8>), Variant2(u8), Variant3(String), Variant4(f32), Variant6(f32) Variant5(bool, bool, String) } Naming tags for something like this would be hard. Some of the fields would be shared between variants. Some would not.

weberc2 10y ago
> Of course they are. What if you read from or write to the wrong field? This falls under the rubric of "not meaningfully less type safe". This data structure is central in a large project of mine, and I have maybe 3 places where I switch on the type flag. I'm not proposing this as a general purpose replacement for interfaces, only a useful way to abstract over a few known types when you can't afford all of the allocs. > Your example has one contained type per variant. In Rust it is common to have an enum like enum Foo { Variant1(String, u8, Vec<u8>), Variant2(u8), Variant3(String), Variant4(f32), Variant6(f32) Variant5(bool, bool, String) } I agree. I don't propose this as a general purpose replacement for Rust's enums.
- Manishearth 10y ago
  > I agree. I don't propose this as a general purpose replacement for Rust's enums. Yeah, that's the thing, Rust enums used this way are very powerful. I'm fine with making tagged structy things in cases like the one mentioned, I feel Go can handle that. I'm missing out on all the useful stuff I can do with proper algebraic datatypes.