Hacker News Reader

Comment by stouset | Hacker News Reader

These are the sorts of things type systems try and help avoid. Having the same crappy behavior as an '80s scientific calculator isn't exactly something to strive for.

That said, this is probably such a simple use that it's not worth having Degree and Radian classes in core.

View on HN

Not really. I'm for strong typing, but not all mathematical concepts need to be a separate type. Should we have separate type for 'ratio' or 'real' or 'natural'? A radian is still represented as a number -- specifically a float, generally. This is more like Rust building out a standard Math library, a la Node.js or C/C++. Since rust is aiming at being a C replacement, I can understand why they'd include this.

Some languages do include "natural" in their numeric tower.

This is similar to having 3D position and direction in different types (e.g. point and vector instead of a generic 4-component vector). It looks nice in theory, and it is 'type safe' (e.g. you can't add 2 points, only point+vector or vector+vector), but writing real-world code with this is awkward.

It's a number associated with a unit. Making it a distinct type, even when the underlying representation is a float, makes it harder to make mistakes by substituting or combining units inappropriately.

This sort of stuff works really well when the type system incorporates units of measure directly (usually as some kind of generic type parameter). F# is a good example.

Hm, I'm likely thinking about it wrong, but I don't see why you'd even necessarily want a type system to stop that... Is it not similar to running, which I expect to work?:

    var s1 = "blah"
    var s2 = s1 as string
    var s3 = s2 as string

edit: Nevermind, I guess you're wanting like types for units of measurement. Sounds interesting.

Most readers would expect the "as string" statement to be idempotent; to_radians() isn't, because it's actually implicitly degrees_to_radians(). If your type system isn't going to keep track of which quantities were already degrees, then your function names should be a little more explicit about the fact that value.to_radians().to_radians() is both converting and reinterpreting, twice.

I see, I had missed that detail. Thanks for the explaining it!

Is the best way to solve that problem by introducing "unit measurement" types that are more specific than general numerical types? Or is there another way? Or even a general concept I can go read about? Thanks in advance!

Reply on news.ycombinator.com