4 ms·

> In summary, a typed constant obeys all the rules of typed values in Go. I think this is too optimistic. For example, you can divide by a 0 value but not by a

> In summary, a typed constant obeys all the rules of typed values in Go. I think this is too optimistic. For example, you can divide by a 0 value but not by a 0 constant: 1.0 / 0.0 // compile error but zero := 0.0 1.0 / zero // infinity Or try: foo := 0.0 fmt.Printf("%f", -foo) // outputs -0.0 fmt.Printf("%f", -0.0) // outputs 0.0 So negating a zero value is different than negating a zero constant. Rather confusing.

deleted 12y ago
[deleted]
dsymonds 12y ago
That section is talking about typing. In that sense, a typed constant obeys all the [type] rules of typed values in Go. It's true that dividing by zero is different, but there's lots of other more obvious ones, such as a typed value being assignable (and usually addressable).
pcwalton 12y ago
Interesting. IEEE 754 allows either behavior (trapping or not) for division by zero, but it requires that -0.0 yield a different value from 0.0 (that nevertheless compares equal to it but can be distinguished via copysign or reciprocal).
deleted 12y ago
[deleted]
Tloewald 12y ago
Seems like they've eliminated a class of subtle bugs and introduced a new class of subtle bugs. I can understand why mixing signed and unsigned types leads to subtle bugs, but not being able to mix floating types and integer types is, in practice, a big pain in the butt and I'm not convinced it's preventing anything bad from happening -- it just wraps bugs in casts.
- jerf 12y ago
  To really do this right, a cast probably should have been able to fail, but this really complexifies code. On the other hand, only a certain restricted class of casts can truly not fail and I wish Go could tell the difference. To be honest, this seems like one of those places where Go suffers from having paid a little less attention to the mainstream of type theory than I'd like. One of the things I think we can learn from our various experiments and years of experience with code is that any sharp bit of the code will eventually come out and bite your program. No matter how inconvenient it is to have to deal with errors on truncation, if you make it "easy" and just silently eat the extra bits, it will eventually cause bugs, pretty much every time. I mean that fairly literally... it boggles my mind that damn near every time I set to use a number I encounter this problem incredibly regularly. I'd really like to be able to use uints more often, but it's too easy for them to blow up in your face instead of helpfully restricting the range of things you have to think about, as a type should. You can tell the Go authors over the years have independently rediscovered a lot of the same principles, because Go is a lot more careful than C or a number of other extant languages in a lot of places, but there's the occasional blind spot like the numeric type hierarchy. I've come to like Go in a lot of ways, but I find dealing with the numeric types a bit of a throwback... I wish I could flip a flag or something and get panics on overflows or underflows instead of silent truncation. It's an annoyingly difficult bug to track down sometimes.
  - JoeAltmaier 12y ago
    Funny, I haven't had but a few truncation bugs in 20 years. And only when doing math on rates etc. Where I know they can occur, and do a diligent job of testing, so no issue. I think this is overblown. Should every i++ have to deal with truncation issues? This would overburden code pointlessly.
    - jerf 12y ago
      From my training in other languages, I really want to use uint on values that have no meaning when negative. If you look at that statement with C eyes, that probably sounds insane, but if you look at it from a modern type system perspective, it sounds eminently sensible and if anything not paranoid enough (where's your upper bound?). Unfortunately it's too darned easy to casually subtract something and bam, Big Numbers due to underflow. What I want is to be told I have bug... what I get is just the bug. I've also encountered it in some network code where the numbers in question were bitpacked. I mean, sure, it's my bug, but philosophically I no longer think that's the end of the story. Anything a compiler or runtime can do to help me avoid bugs, it should, and noticing a truncation is definitely in that class. Again, that statement may sound crazy in a C world, but it's perfectly sensible in a modern one. You don't get truncation bugs because you're so used to not getting any help that you just do bad things like not correctly specify your type, because you've thoroughly internalized how bad and wrong the compiler and runtime are here. You shouldn't have to lie about your types to make your code work.

deleted 12y ago

[deleted]

dsymonds 12y ago

That section is talking about typing. In that sense, a typed constant obeys all the [type] rules of typed values in Go. It's true that dividing by zero is different, but there's lots of other more obvious ones, such as a typed value being assignable (and usually addressable).

pcwalton 12y ago

Interesting. IEEE 754 allows either behavior (trapping or not) for division by zero, but it requires that -0.0 yield a different value from 0.0 (that nevertheless compares equal to it but can be distinguished via copysign or reciprocal).

deleted 12y ago

[deleted]

Tloewald 12y ago

Seems like they've eliminated a class of subtle bugs and introduced a new class of subtle bugs. I can understand why mixing signed and unsigned types leads to subtle bugs, but not being able to mix floating types and integer types is, in practice, a big pain in the butt and I'm not convinced it's preventing anything bad from happening -- it just wraps bugs in casts.

jerf 12y ago
To really do this right, a cast probably should have been able to fail, but this really complexifies code. On the other hand, only a certain restricted class of casts can truly not fail and I wish Go could tell the difference. To be honest, this seems like one of those places where Go suffers from having paid a little less attention to the mainstream of type theory than I'd like. One of the things I think we can learn from our various experiments and years of experience with code is that any sharp bit of the code will eventually come out and bite your program. No matter how inconvenient it is to have to deal with errors on truncation, if you make it "easy" and just silently eat the extra bits, it will eventually cause bugs, pretty much every time. I mean that fairly literally... it boggles my mind that damn near every time I set to use a number I encounter this problem incredibly regularly. I'd really like to be able to use uints more often, but it's too easy for them to blow up in your face instead of helpfully restricting the range of things you have to think about, as a type should. You can tell the Go authors over the years have independently rediscovered a lot of the same principles, because Go is a lot more careful than C or a number of other extant languages in a lot of places, but there's the occasional blind spot like the numeric type hierarchy. I've come to like Go in a lot of ways, but I find dealing with the numeric types a bit of a throwback... I wish I could flip a flag or something and get panics on overflows or underflows instead of silent truncation. It's an annoyingly difficult bug to track down sometimes.
- JoeAltmaier 12y ago
  Funny, I haven't had but a few truncation bugs in 20 years. And only when doing math on rates etc. Where I know they can occur, and do a diligent job of testing, so no issue. I think this is overblown. Should every i++ have to deal with truncation issues? This would overburden code pointlessly.
  - jerf 12y ago
    From my training in other languages, I really want to use uint on values that have no meaning when negative. If you look at that statement with C eyes, that probably sounds insane, but if you look at it from a modern type system perspective, it sounds eminently sensible and if anything not paranoid enough (where's your upper bound?). Unfortunately it's too darned easy to casually subtract something and bam, Big Numbers due to underflow. What I want is to be told I have bug... what I get is just the bug. I've also encountered it in some network code where the numbers in question were bitpacked. I mean, sure, it's my bug, but philosophically I no longer think that's the end of the story. Anything a compiler or runtime can do to help me avoid bugs, it should, and noticing a truncation is definitely in that class. Again, that statement may sound crazy in a C world, but it's perfectly sensible in a modern one. You don't get truncation bugs because you're so used to not getting any help that you just do bad things like not correctly specify your type, because you've thoroughly internalized how bad and wrong the compiler and runtime are here. You shouldn't have to lie about your types to make your code work.