4 ms·

If you have a look at swift, it's also very explicit, and non-magical ( which is why i like it so much). The difference with go is that you can't make any type

by bsaul 10y ago

If you have a look at swift, it's also very explicit, and non-magical ( which is why i like it so much). The difference with go is that you can't make any type error when unwrapping the enum, because the compiler knows what are the different possibilities. I see no reason for go not to adopt it, in all honesty. it's nothing like generics, because it doesn't seem to add complexity to the rest of the language ( imho ).

brandonbloom 10y ago
> you can't make any type error when unwrapping the enum This is also true in Go with type switches: switch y := x.(type) case MyStruct: And with type assertions: y, ok := x.(MyInterface) In both cases, y is of the correct type. The ok is optional, if omitted and the assertion fails, you'll get a runtime panic.
- dbaupp 10y ago
  y is of the type you asked for, yes, but that isn't necessarily the type that should be there if the programmer makes a mistake, or if the underlying code changes. With an enum, the types are written in one place, and the compiler connects the dots, giving compile-time errors about mistakes/mismatched expectations. This similar to how one can call `foo(x)` and the return value's type is known, no need to first cast the function to the type the programmer thinks it should be. The casting pushes type errors to execution-time rather than compile-time.
  - brandonbloom 10y ago
    > The casting pushes type errors to execution-time rather than compile-time Which is exactly what pattern matching does, which is what I was responding about.
    - bsaul 10y ago
      Ok, i'm starting to understand what we're disagreeing on. You're talking about pattern matching with dynamic expressions ( don't know the official name for that), such as what you find in erlang, i'm talking very basic enum unwrapping based on types, which is compile time checked. Swift also adds some kind of dynamic expression to patterns, which may break exhaustiv checking, but in the case of go, just a simple type check would be a great start. Edit ( since i can't reply) : just look at https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Enumerations.html https://developer.apple.com/library/content/documentation/Sw... with something like the barcode example. It's all compile time checked.
      - brandonbloom 10y ago
        > very basic enum unwrapping based on types, which is compile time checked Sooo just accessing fields on a struct? I don't understand the distinction you are trying to make.
        dbaupp 10y ago
        It's like accessing fields on a struct, where you can only access the ones that are guaranteed to be valid. For instance, in existing Go, the struct method would be having two fields, * X and * Y, where (in theory) exactly one of them is non-nil, but both can still be accessed. This requires manually maintaining this invariant (and remembering to check when accessing), as well as sacrificing performance by allocating. Using an ADT would allow storing the X and Y by value, as well as guaranteeing that the invariant of "X xor Y" is always true.
        brandonbloom 10y ago
        Sounds like type-assertions cover that use case just fine. However, you are correct that you can't do this without allocating. ¯\_(ツ)_/¯
        dbaupp 10y ago
        As people keep saying, type assertions do not have as strong compile time assurances as ADTs.
- bsaul 10y ago
  I'm sorry, i meant trying to unwrap to a type that's not even possible ( and forgeting to check for one that is). Sure, there are ways to dynamically ensure typecasts have succeeded.
  - brandonbloom 10y ago
    Go will give you errors for "impossible type assertions" in many cases.
- codygman 10y ago
  > The ok is optional, if omitted and the assertion fails, you'll get a runtime panic. Great, now my enums can panic because I have to play "be the typechecker", instead of focusing on something actually important like business logic. How is this not seen as universally a bad thing?

by bsaul 10y ago

brandonbloom 10y ago

> you can't make any type error when unwrapping the enum This is also true in Go with type switches: switch y := x.(type) case MyStruct: And with type assertions: y, ok := x.(MyInterface) In both cases, y is of the correct type. The ok is optional, if omitted and the assertion fails, you'll get a runtime panic.

dbaupp 10y ago
y is of the type you asked for, yes, but that isn't necessarily the type that should be there if the programmer makes a mistake, or if the underlying code changes. With an enum, the types are written in one place, and the compiler connects the dots, giving compile-time errors about mistakes/mismatched expectations. This similar to how one can call `foo(x)` and the return value's type is known, no need to first cast the function to the type the programmer thinks it should be. The casting pushes type errors to execution-time rather than compile-time.
- brandonbloom 10y ago
  > The casting pushes type errors to execution-time rather than compile-time Which is exactly what pattern matching does, which is what I was responding about.
  - bsaul 10y ago
    Ok, i'm starting to understand what we're disagreeing on. You're talking about pattern matching with dynamic expressions ( don't know the official name for that), such as what you find in erlang, i'm talking very basic enum unwrapping based on types, which is compile time checked. Swift also adds some kind of dynamic expression to patterns, which may break exhaustiv checking, but in the case of go, just a simple type check would be a great start. Edit ( since i can't reply) : just look at https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Enumerations.html https://developer.apple.com/library/content/documentation/Sw... with something like the barcode example. It's all compile time checked.
    - brandonbloom 10y ago
      > very basic enum unwrapping based on types, which is compile time checked Sooo just accessing fields on a struct? I don't understand the distinction you are trying to make.
      - dbaupp 10y ago
        It's like accessing fields on a struct, where you can only access the ones that are guaranteed to be valid. For instance, in existing Go, the struct method would be having two fields, * X and * Y, where (in theory) exactly one of them is non-nil, but both can still be accessed. This requires manually maintaining this invariant (and remembering to check when accessing), as well as sacrificing performance by allocating. Using an ADT would allow storing the X and Y by value, as well as guaranteeing that the invariant of "X xor Y" is always true.
        brandonbloom 10y ago
        Sounds like type-assertions cover that use case just fine. However, you are correct that you can't do this without allocating. ¯\_(ツ)_/¯
        dbaupp 10y ago
        As people keep saying, type assertions do not have as strong compile time assurances as ADTs.
bsaul 10y ago
I'm sorry, i meant trying to unwrap to a type that's not even possible ( and forgeting to check for one that is). Sure, there are ways to dynamically ensure typecasts have succeeded.
- brandonbloom 10y ago
  Go will give you errors for "impossible type assertions" in many cases.
codygman 10y ago
> The ok is optional, if omitted and the assertion fails, you'll get a runtime panic. Great, now my enums can panic because I have to play "be the typechecker", instead of focusing on something actually important like business logic. How is this not seen as universally a bad thing?