7 ms·
A clickable visual guide to the Rust type system
- craftkiller 1y agoThis is such a small thing, but I love the inclusion of the value ranges for the integers! I can never remember which side can go one deeper ("is it [-128 to 127] or [-127 to 128]"). Bookmarking this for reference later!
- throwawaymaths 1y agoIt's always negative. 0xFFFF... Cannot have a two's complement, and the top bit is set.
- delusional 1y agoI find that the easiest way to remember it is to remember that 0 is positive but has no negative counterpart.
- high_priest 1y agoThe 0 is positive is not true, but some day you are hopefully going to get it. The true answer is that negative numbers have the top bit set, which can't be used for positive numbers. Hence positives are one bit short.
- delusional 1y agoYoure literally saying the same thing as me. All negative numbers have the most significant bit set and 0 is the number with no bits set, ergo 0 must be positive since the most significant bit is not set. Now arithmatically, this is untrue. We'll usually treat 0 as neither positive nor negative (or in certain cases both negative and positive) but bitwise, In terms of twos-complement implementation, Zero is positive. We know that since it exists in the unsigned version of the types as well. Hopefully you'll see that some day.
- jibal 1y agoI can't imagine suffering from that. Understanding twos complement representation is an essential programming skill. And a byte value of 128? What is that in hex?
- craftkiller 1y agoEh, how often are you going down to the bit representation of signed integers? Naturally I learned two's complement ages ago, but all of my bitwise manipulation seems to be on unsigned integers (and frankly I've only used bitwise operations at work once for implementing bloom filters. Normally I only get to do lower level stuff like that in side-projects). So internalizing two's complement has never seemed relevant. > And a byte value of 128? What is that in hex? 0x80
- jibal 1y ago> 0x80 Which is of course has the sign bit set. The comments here are educational ... I hadn't realized that the field of programming had become this degraded.
- superblas 1y agoSuch needless condescension, jibal.
- craftkiller 1y agoOn the contrary, there is no sign bit. You asked for 128 which is either: 1. Unrepresentable in S8 2. Representable in U8 as shown in my above comment. 3. Representable in S16 as 0x0080 but then the sign bit is not set. My comment accurately represents the hex encoding for #2.
- jibal 1y ago> Such needless condescension, jibal. THAT comment is condescending--talk about ideas, not people. I condescended to no one ... my issue is the state of computer science education. > On the contrary, there is no sign bit. You asked for 128 I didn't ask for anything. The subject here was the value range of the i8 type.
- newpavlov 1y agoTangential note: I sometimes wish that signed integers were symmetrical. i8 would represent the range of [-127 to 127] with 0xFF representing NaN. Any operation which can not be computed (division by zero, overflows, operation with another NaN, etc.) would result in NaN. For further symmetry we could do the same for signed integers as well. Yes, it's possible to encode such types manually, but it will not be efficient since CPUs do not natively support such operations.
- lock1 1y agoWouldn't this make CPU flags useless? I think it would complicate branch instructions too, as most modern CPUs tend to use integer operations for branching. Also, this in-band signaling probably would invite something similar to `null` mess in type systems. I can't wait to tell CPU to JMP NaN.
- newpavlov 1y ago>Wouldn't this make CPU flags useless? They would, but I agree with RISC-V here, CPUs should not rely on them in the first place. I do not understand your argument about branches, how would it hinder the jump instructions? We still would need separate "wrapping" instructions (e.g. for implementing bigints and cryptographic algorithms), but they probably could be limited to unsigned operations only. >I can't wait to tell CPU to JMP NaN. How is it different from jumping to null? If you do such jump, it means you have a huge correctness problem with your code.
- lock1 1y ago> I do not understand your argument about branches, how would it hinder the jump instructions? Extra set of logic for handling NaN cases? I don't think it's impossible, just kind of less intuitive. Jump instruction using integer w/o NaN always valid, while NaN-able integer sometimes invalid (ignoring whether the memory address can be accessed).
- newpavlov 1y ago
- smj-edison 1y agoI really like how it scrolls left-to-right on mobile, instead of collapsing down.
- goku12 1y agoAdding another resource I use frequently: https://cheats.rs/ https://cheats.rs/ One part that I love especially about it is that it represents lifetimes [1] and memory layout [2] of data structures in graphical format. They're as invaluable as API references. I would love to see it included in other documentation as well. [1] https://cheats.rs/#memory-lifetimes https://cheats.rs/#memory-lifetimes [2] https://cheats.rs/#memory-layout https://cheats.rs/#memory-layout
- 6r17 1y agoThere aren't that much of them actually ! Almost feel like an element table
- adastra22 1y agoWhy is PhantomData in the unsafe support group?
- john-h-k 1y agoIt obviously can be used for other things but it principally was designed for unsafe support (allowing dropck to understand unsafe types that own a value through a pointer). See https://doc.rust-lang.org/nomicon/phantom-data.html https://doc.rust-lang.org/nomicon/phantom-data.html
- saghm 1y agoInteresting, I've had to use it a number of times over the years despite never really doing much unsafe. At least to me, it seems pretty well-scoped as a workaround from the requirements that the compiler has around needing to use generic type parameters in type definitions, which certainly isn't something you need to be writing unsafe code to run into. I wouldn't be shocked if it used unsafe under the hood, but then again, so does Vec.
- afdbcreid 1y agoThe original reason to design it (instead of the previously inferred bivariance) was so that unsafe code that really does not want bivariance, and will be unsound if it will be used, will remember to consider that. It doesn't use unsafe under the hood, rather it's compiler magic.
- john-h-k 1y ago> At least to me, it seems pretty well-scoped as a workaround from the requirements that the compiler has around needing to use generic type parameters in type definitions The reason those requirements exist is (primarily) to do with unsafe code. Specifically it’s about deciding the variance of the type (which doesn’t matter for a truely unused type parameter).
- stmw 1y agoIt's very good, thanks for getting it some attention. Also - to show how much I agree - https://news.ycombinator.com/item?id=45140572 https://news.ycombinator.com/item?id=45140572
- shmerl 1y agoReally nice and concise presentation!
- wiredpancake 1y ago[dead]
- mattlutze 1y agoI love a page that doesn't react to my browser width.