3 ms·

I imagine that this is to keep compatibility with C. And also, this ensures that when a Left value is accidentally read as a Right one, you don't get a "random"

by emillon 14y ago

I imagine that this is to keep compatibility with C. And also, this ensures that when a Left value is accidentally read as a Right one, you don't get a "random" bit pattern due to type punning, but a correct (albeit meaningless) value such as NULL.

sausagefeet 14y ago
I'm not sure how, C doesn't have multiple return values either. I also don't really understand the second part. How is that any worse than the current situation of not checking the error side and reading an undefined (or whatever it is?) value?
- potkor 14y ago
  >> when a Left value is accidentally read as a Right one, you don't get a "random" bit pattern due to type punning, but a correct (albeit meaningless) value such as NULL > How is that any worse than the current situation of not checking the error side and reading an undefined (or whatever it is?) value? You get deterministic failure modes instead of dragons flying out of your nose. Also assigning error in a variable ignoring it sticks out a lot more. The single-return value C version doesn't tell you if it can return failure or not. edit: fixed quoting
  - sausagefeet 14y ago
    > You get deterministic failure modes instead of dragons flying out of your nose What Go currently has does not solve this problem, which is what I'm pointing out. Your argument is basically "not handling the error Looks Bad". Mine is "It should be impossible to do wrong". Something like ADT's would have been very welcomed, then we could just have a classy option type or either type.
- emillon 14y ago
  Well, the choice is between structures or tagged unions. I'm not a Go user, but if I understand correctly ("It's like an Either that always has Left and Right."), functions return a structure with both an error code and a value. To wrap a C function into a Go function with this signature, you can initialize a structure with { code: success; value:f() }; and then of course error checking has to be done C-style (errno, lib_last_error(), etc). The problem with tagged unions is that when you access the wrong field (when it's not enforced by the language), everything can happen : you can build ill-formed values, jump to random places, etc. Having an explicit NULL in that cases is better. In a nutshell, unsafe tagged unions < explicit NULLs < safe tagged unions.
  - icebraining 14y ago
    Go actually returns true multiple values, not a structure. You can't assign it to a single variable, for example, you actually have to assign it to N variables, with N being the number of values the function returns.
  - Evbn 14y ago
    By "unsafe tagged unions" you mean "untagged unions" (or ad hoc runtime-tagged unions)?

by emillon 14y ago

sausagefeet 14y ago

I'm not sure how, C doesn't have multiple return values either. I also don't really understand the second part. How is that any worse than the current situation of not checking the error side and reading an undefined (or whatever it is?) value?

potkor 14y ago
>> when a Left value is accidentally read as a Right one, you don't get a "random" bit pattern due to type punning, but a correct (albeit meaningless) value such as NULL > How is that any worse than the current situation of not checking the error side and reading an undefined (or whatever it is?) value? You get deterministic failure modes instead of dragons flying out of your nose. Also assigning error in a variable ignoring it sticks out a lot more. The single-return value C version doesn't tell you if it can return failure or not. edit: fixed quoting
- sausagefeet 14y ago
  > You get deterministic failure modes instead of dragons flying out of your nose What Go currently has does not solve this problem, which is what I'm pointing out. Your argument is basically "not handling the error Looks Bad". Mine is "It should be impossible to do wrong". Something like ADT's would have been very welcomed, then we could just have a classy option type or either type.
emillon 14y ago
Well, the choice is between structures or tagged unions. I'm not a Go user, but if I understand correctly ("It's like an Either that always has Left and Right."), functions return a structure with both an error code and a value. To wrap a C function into a Go function with this signature, you can initialize a structure with { code: success; value:f() }; and then of course error checking has to be done C-style (errno, lib_last_error(), etc). The problem with tagged unions is that when you access the wrong field (when it's not enforced by the language), everything can happen : you can build ill-formed values, jump to random places, etc. Having an explicit NULL in that cases is better. In a nutshell, unsafe tagged unions < explicit NULLs < safe tagged unions.
- icebraining 14y ago
  Go actually returns true multiple values, not a structure. You can't assign it to a single variable, for example, you actually have to assign it to N variables, with N being the number of values the function returns.
- Evbn 14y ago
  By "unsafe tagged unions" you mean "untagged unions" (or ad hoc runtime-tagged unions)?