3 ms·

> 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.
        brandonbloom 10y ago
        And as I keep saying: I don't value those assurances and in fact find them to be a net loss when accounting for breaking changes changes to clients.
        dbaupp 10y ago
        You personally not valuing the differences is very different to not having any differences, and the latter is what a lot of your comments seem to be implying, including the one I was replying to.
        codygman 10y ago
        You pay the price of getting the bugs and edge cases out regardless of whether you have compile time assurances. The complexity is inherent and you can either choose to make it implicit and play the losing game of ensuring it doesn't fail with tests or make it explicit from the outset.

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.
      - brandonbloom 10y ago
        And as I keep saying: I don't value those assurances and in fact find them to be a net loss when accounting for breaking changes changes to clients.
        dbaupp 10y ago
        You personally not valuing the differences is very different to not having any differences, and the latter is what a lot of your comments seem to be implying, including the one I was replying to.
        codygman 10y ago
        You pay the price of getting the bugs and edge cases out regardless of whether you have compile time assurances. The complexity is inherent and you can either choose to make it implicit and play the losing game of ensuring it doesn't fail with tests or make it explicit from the outset.