6 ms·

Rust doesn't allow them either: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ba32a5a3108438d3dae8300ee6eb9dcc https://play.rust-lang.

by est31 5y ago

Rust doesn't allow them either: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ba32a5a3108438d3dae8300ee6eb9dcc https://play.rust-lang.org/?version=stable&mode=debug&editio... Adding .into() works though, which is the recommended method if the conversion can be statically guaranteed (otherwise try_into should be used, which will become easier in the 2021 edition as the TryInto trait will become part of the prelude).

ridiculous_fish 5y ago
into() does not work from size. It's rather frustrating in practice. https://stackoverflow.com/questions/62832438/why-is-rusts-usize-to-u128-conversion-considered-failable https://stackoverflow.com/questions/62832438/why-is-rusts-us...
- masklinn 5y ago
  > It's rather frustrating in practice. All explicit conversions, more so fallible, are "frustrating in practice" especially when coming from a language without those foibles. But given the semantics of usize/isize, it is perfectly reasonable, nay, a good thing, that they're considered neither widenings nor narrowings of other numeric types.
  - ridiculous_fish 5y ago
    usize should be Into<u64> iff usize is <= 64 bit. usize is already on that hook: `0x100000000usize` will fail to compile in 32 bit, so you already risk compile errors when switching archs. As it is I'm just writing `as u64` which is clearly worse.
- eloff 5y ago
  Yeah, that is frustrating since there are no platforms where that would fail today, and it's hard to imagine why we would ever want one with 256bit pointers. We don't even use full 64bit pointers today on x64.
  - mgraczyk 5y ago
    The Ethereum virtual machine addresses it's storage with 256 bits, so there's one wild example. Although in this case you'd probably not want to use usize directly to represent storage.
    - eloff 5y ago
      I'm not familiar with the Ethereum virtual machine, are these really memory pointers? Surely it's represented differently?
      - mgraczyk 5y ago
        EVM is a stack machine, and it has durable storage which is addressed using 256 bit "pointers". So you can do something like push x // 256 bit constant LOAD // top of stack now contains storage[x]
  - est31 5y ago
    When 16 bit computers went to 32 bit, people probably thought that one wouldn't ever need 64 bit computers either. That being said, by the time 128 bit run out we have probably boiled earths oceans :). You could think of checked memory models where half of the 256 bit address is a 128 bit random key needed to access some allocation, or maybe even a decryption key. Similar things are done with the extra space of x64 as well. Also, 128 bit numbers are still quite uncommon in Rust. Easy conversion of usize to them wouldn't be that useful if conversions of the other number types don't work.
    - a1369209993 5y ago
      > When 16 bit computers went to 32 bit, people probably thought that one wouldn't ever need 64 bit computers either. People have said that about pretty much every memory size in the history of computing. The argument for 64-bit is not "2^64 bytes ought to be enough for anyone"; it's "you couldn't use more than 2^64 bytes even if you wanted to". Writing a full register worth of data every clock cycle at 4GHz works out to 32GB/s. (2^64B / 32GB/s) is just over seventeen years, to fill up a 64-bit address space, assuming you're doing no actual computation. Few computers even work for seventeen years without replacement, much less run single processes continually with no reboots.

by est31 5y ago

ridiculous_fish 5y ago

into() does not work from size. It's rather frustrating in practice. https://stackoverflow.com/questions/62832438/why-is-rusts-usize-to-u128-conversion-considered-failable https://stackoverflow.com/questions/62832438/why-is-rusts-us...

masklinn 5y ago
> It's rather frustrating in practice. All explicit conversions, more so fallible, are "frustrating in practice" especially when coming from a language without those foibles. But given the semantics of usize/isize, it is perfectly reasonable, nay, a good thing, that they're considered neither widenings nor narrowings of other numeric types.
- ridiculous_fish 5y ago
  usize should be Into<u64> iff usize is <= 64 bit. usize is already on that hook: `0x100000000usize` will fail to compile in 32 bit, so you already risk compile errors when switching archs. As it is I'm just writing `as u64` which is clearly worse.
eloff 5y ago
Yeah, that is frustrating since there are no platforms where that would fail today, and it's hard to imagine why we would ever want one with 256bit pointers. We don't even use full 64bit pointers today on x64.
- mgraczyk 5y ago
  The Ethereum virtual machine addresses it's storage with 256 bits, so there's one wild example. Although in this case you'd probably not want to use usize directly to represent storage.
  - eloff 5y ago
    I'm not familiar with the Ethereum virtual machine, are these really memory pointers? Surely it's represented differently?
    - mgraczyk 5y ago
      EVM is a stack machine, and it has durable storage which is addressed using 256 bit "pointers". So you can do something like push x // 256 bit constant LOAD // top of stack now contains storage[x]
- est31 5y ago
  When 16 bit computers went to 32 bit, people probably thought that one wouldn't ever need 64 bit computers either. That being said, by the time 128 bit run out we have probably boiled earths oceans :). You could think of checked memory models where half of the 256 bit address is a 128 bit random key needed to access some allocation, or maybe even a decryption key. Similar things are done with the extra space of x64 as well. Also, 128 bit numbers are still quite uncommon in Rust. Easy conversion of usize to them wouldn't be that useful if conversions of the other number types don't work.
  - a1369209993 5y ago
    > When 16 bit computers went to 32 bit, people probably thought that one wouldn't ever need 64 bit computers either. People have said that about pretty much every memory size in the history of computing. The argument for 64-bit is not "2^64 bytes ought to be enough for anyone"; it's "you couldn't use more than 2^64 bytes even if you wanted to". Writing a full register worth of data every clock cycle at 4GHz works out to 32GB/s. (2^64B / 32GB/s) is just over seventeen years, to fill up a 64-bit address space, assuming you're doing no actual computation. Few computers even work for seventeen years without replacement, much less run single processes continually with no reboots.