5 ms·

Indeed. Go types are like simple locks: they keep honest users honest, but they don't prevent dishonest users from breaking your assumptions. The point is just

by kiitos 3y ago

Indeed. Go types are like simple locks: they keep honest users honest, but they don't prevent dishonest users from breaking your assumptions. The point is just that "compile-time type safety for enumerations" isn't actually true, or even possible. You always have to do some amount of runtime validation of received values.

chabad360 3y ago
No, you don't. If your module relies on compile time checks for validity, there's no reason for you to also include runtime checks. Other developers breaking your defined contract is not your responsibility, it's not even a bug.
- kiitos 3y ago
  > If your module relies on compile time checks for validity, ...then it's broken, because the Go compiler, factually, cannot (in general) check or enforce the validity of specific values. > there's no reason for you to also include runtime checks. Other developers breaking your defined contract is not your responsibility, it's not even a bug. It is absolutely the responsibility of the function func PrintColor(c Color) to ensure, at runtime, that `c` is a valid Color. My example code -- which allowed an invalid Color value of "orange" -- is absolutely a bug in PrintColor.
  - ori_b 3y ago
    Exactly. Someone could always connect to your program with a debugger and modify the instructions are being run, and that's why you need to regular runtime checks of the validity of your program text. If you want to handle people actively trying to undermine the assumptions your program is making, you can't leave out easy to replicate cases like 'gdb attach', obvious, non-accidental use of the type system, and other similar categories of issues. What strategies do you use in your programs to ensure type safety in the event of debugging, mmap, and other mechanisms that can be used to subvert the memory layouts your compiler thinks it produced?
    - athrun 3y ago
      That doesn't make any sense to me. Most instructions are not atomic, so even if you had runtime checks something like a debugger could still inject invalid state in between your checks, making them ineffective. If real-time code injection is your threat model, I don't see how runtime checks would get you anywhere.
      - wahern 3y ago
        You seem to be suggesting that (to use a common phrase) if something can be done, it should be done. The previous poster's example regarding a debugger was to challenge the notion that there was any meaningful reason to constrain non-accidental type subversion. You seem to be saying it's absurd to care about someone using a debugger to inject invalid code at runtime because there's nothing you can do about it, thus implying if you can do something, you should. But that only begs the question--why should you? To some people, defending against debugger code injection is no more absurd than defending against other examples where the programmer deliberately alters code to subvert static type checking. If you disagree then articulating more meaningful distinctions among cases would be worthwhile. Mere ability is generally not considered sufficient justification alone to do something.
        kiitos 3y ago
        This is an inane comparison. Casting as demonstrated in the example is normal and has to be expected. Go types aren't as strict as types in other languages. Code can't assume otherwise.
        ori_b 3y ago
        > Casting as demonstrated in the example is normal and has to be expected. Can you give an example where someone has done similar casts accidentally? It seems like it would be hard to accidentally typo. That leaves malice, which seems difficult to defend against, in light of the kinds of system calls that are available to a program.
  - gabereiser 3y ago
    It’s actually not and is one of those Java isms that have made its way into generalized software engineering. If I write a function that takes Foo as an argument. I have a Foo implementation exposed elsewhere in my program. It is absolutely expected that I mean MY Foo, not your Foo. If you pass me your Foo, you will get unexpected results that are not a bug, not a side effect, not my responsibility. It’s yours, the caller, to adhere to the contract. There are valid reasons to not adhere. To pass your own implementation. At that point, you are responsible for its use. Not me. If it adheres to MY Foo’s interface, you might get by, but it’s is not my responsibility to validate all permutations of unknown types to ensure you’re passing me mine. In go, it’s perfectly valid to return structs but accept interfaces as arguments so that you, the program author calling my api, can craft the correct program flow. So please, leave that runtime type check reflection for Java and C# and the land of JS. We have no need for it here in machine code land.
    - kiitos 3y ago
      > it’s is not my responsibility to validate all permutations of unknown types to ensure you’re passing me mine. Of course it is! If you provide an API that takes a Color, and you define valid Colors as exclusively Red, Green, and Blue, then you are absolutely responsible for validating input Color values and rejecting anything which is not Red, Green, or Blue. If you delegate that responsibility to the caller, then your API provides no meaningful encapsulation, and isn't a useful abstraction -- it's entirely leaky. No bueno.
      - Nullabillity 3y ago
        By the same token, Rust has no type safety because std::mem::transmute exists. In practice, it's not a problem because transmute is not a valid way to construct or interact with values (outside of a few special cases). By calling transmute you're explicitly opting out of all safety and abstraction, and entering here-be-dragons territory. (That said, the Go syntax looks far less "scary" than `unsafe { transmute::<_, Colour>("orange") }`, which I'd definitely call a design issue.)
        3y ago

by kiitos 3y ago

chabad360 3y ago

No, you don't. If your module relies on compile time checks for validity, there's no reason for you to also include runtime checks. Other developers breaking your defined contract is not your responsibility, it's not even a bug.

kiitos 3y ago
> If your module relies on compile time checks for validity, ...then it's broken, because the Go compiler, factually, cannot (in general) check or enforce the validity of specific values. > there's no reason for you to also include runtime checks. Other developers breaking your defined contract is not your responsibility, it's not even a bug. It is absolutely the responsibility of the function func PrintColor(c Color) to ensure, at runtime, that `c` is a valid Color. My example code -- which allowed an invalid Color value of "orange" -- is absolutely a bug in PrintColor.
- ori_b 3y ago
  Exactly. Someone could always connect to your program with a debugger and modify the instructions are being run, and that's why you need to regular runtime checks of the validity of your program text. If you want to handle people actively trying to undermine the assumptions your program is making, you can't leave out easy to replicate cases like 'gdb attach', obvious, non-accidental use of the type system, and other similar categories of issues. What strategies do you use in your programs to ensure type safety in the event of debugging, mmap, and other mechanisms that can be used to subvert the memory layouts your compiler thinks it produced?
  - athrun 3y ago
    That doesn't make any sense to me. Most instructions are not atomic, so even if you had runtime checks something like a debugger could still inject invalid state in between your checks, making them ineffective. If real-time code injection is your threat model, I don't see how runtime checks would get you anywhere.
    - wahern 3y ago
      You seem to be suggesting that (to use a common phrase) if something can be done, it should be done. The previous poster's example regarding a debugger was to challenge the notion that there was any meaningful reason to constrain non-accidental type subversion. You seem to be saying it's absurd to care about someone using a debugger to inject invalid code at runtime because there's nothing you can do about it, thus implying if you can do something, you should. But that only begs the question--why should you? To some people, defending against debugger code injection is no more absurd than defending against other examples where the programmer deliberately alters code to subvert static type checking. If you disagree then articulating more meaningful distinctions among cases would be worthwhile. Mere ability is generally not considered sufficient justification alone to do something.
      - kiitos 3y ago
        This is an inane comparison. Casting as demonstrated in the example is normal and has to be expected. Go types aren't as strict as types in other languages. Code can't assume otherwise.
        ori_b 3y ago
        > Casting as demonstrated in the example is normal and has to be expected. Can you give an example where someone has done similar casts accidentally? It seems like it would be hard to accidentally typo. That leaves malice, which seems difficult to defend against, in light of the kinds of system calls that are available to a program.
- gabereiser 3y ago
  It’s actually not and is one of those Java isms that have made its way into generalized software engineering. If I write a function that takes Foo as an argument. I have a Foo implementation exposed elsewhere in my program. It is absolutely expected that I mean MY Foo, not your Foo. If you pass me your Foo, you will get unexpected results that are not a bug, not a side effect, not my responsibility. It’s yours, the caller, to adhere to the contract. There are valid reasons to not adhere. To pass your own implementation. At that point, you are responsible for its use. Not me. If it adheres to MY Foo’s interface, you might get by, but it’s is not my responsibility to validate all permutations of unknown types to ensure you’re passing me mine. In go, it’s perfectly valid to return structs but accept interfaces as arguments so that you, the program author calling my api, can craft the correct program flow. So please, leave that runtime type check reflection for Java and C# and the land of JS. We have no need for it here in machine code land.
  - kiitos 3y ago
    > it’s is not my responsibility to validate all permutations of unknown types to ensure you’re passing me mine. Of course it is! If you provide an API that takes a Color, and you define valid Colors as exclusively Red, Green, and Blue, then you are absolutely responsible for validating input Color values and rejecting anything which is not Red, Green, or Blue. If you delegate that responsibility to the caller, then your API provides no meaningful encapsulation, and isn't a useful abstraction -- it's entirely leaky. No bueno.
    - Nullabillity 3y ago
      By the same token, Rust has no type safety because std::mem::transmute exists. In practice, it's not a problem because transmute is not a valid way to construct or interact with values (outside of a few special cases). By calling transmute you're explicitly opting out of all safety and abstraction, and entering here-be-dragons territory. (That said, the Go syntax looks far less "scary" than `unsafe { transmute::<_, Colour>("orange") }`, which I'd definitely call a design issue.)
      - 3y ago