3 ms·

Speaking of explicit conversions, it's always painful to have to do explicit conversions of integers. E.g. Have an u8 and want to use it as an index in a Vec? Y

Speaking of explicit conversions, it's always painful to have to do explicit conversions of integers. E.g. Have an u8 and want to use it as an index in a Vec? You have to cast as usize. That quickly becomes annoying.

royjacobs 9y ago
If you need to do that a lot then arguably you'd be better off having a variable of 'usize' in the first place.
thinkpad20 9y ago
On the contrary, I think that’s an argument against implicit conversions. u8 and usize have wildly different ranges, and treating them as the same could cause some maddening bugs. I can’t imagine there are that many places where you’d need to use a u8 as an index; if there were you could either wrap your data structure in a struct which accepts u8 instead, or use usize more instead... (Not that I’m claiming to know your code base or specific challenge or anything; I’m just speaking generally)
- userbinator 9y ago
  I think implicit widening is a good idea, but not narrowing --- expanding a u8 into a usize doesn't actually lose any information, but going the opposite way does.
  - therein 9y ago
    Depends on the machine architecture really but I agree in principle.
- Gibbon1 9y ago
  > I can’t imagine there are that many places where you’d need to use a u8 as an index I have some firmware on a small machine, there aren't any arrays with more than two dozen elements. On the eight bit machine the the code originally ran on using a 16 or 32 bit int caused a lot of code bloat. You might not think that's a problem but consider the price difference between a processor with 64k of flash and 128k might be a dollar. Times 100,000 units a year. The above is why I'm not going to use rust anytime soon, because a rust binary size is about 4 times larger than C. That would add about $2-3 to the cost of the product. Or $200-300k a year for no real benefit at all.
  - burntsushi 9y ago
    That doesn't make any sense. If `i` is a `u8` and `xs` is an array, then `xs[i as usize]` works today. The criticism isn't even specific to exotic environments. The same reasoning applies at bigger widths too. I've certainly used `u32` in places instead of `usize` to avoid doubling the size of my heap use on 64-bit systems. Implicit widening would be nice, but it isn't necessary.
    - Gibbon1 9y ago
      In the firmware I mentioned on an 8 bit system using a 16 bit indx increases the resulting code by 2-3X. A lot of times the code size doesn't matter. In my case it's important. Consider a lowly printf statement in my firmware. It takes about 120 bytes of code. A trivial amount! Lets see how much that costs us. Marginal cost of flash is about $1.00/64k. So 120b/64k X $1 = $0.001875 per unit. We ship 100,000 units per year. So that printf costs $187 per year.
      - burntsushi 9y ago
        I feel like you just repeated your previous comment. I don't need a lesson on unit economics. My whole point is that your don't need a 16 bit index.

royjacobs 9y ago

If you need to do that a lot then arguably you'd be better off having a variable of 'usize' in the first place.

thinkpad20 9y ago

On the contrary, I think that’s an argument against implicit conversions. u8 and usize have wildly different ranges, and treating them as the same could cause some maddening bugs. I can’t imagine there are that many places where you’d need to use a u8 as an index; if there were you could either wrap your data structure in a struct which accepts u8 instead, or use usize more instead... (Not that I’m claiming to know your code base or specific challenge or anything; I’m just speaking generally)

userbinator 9y ago
I think implicit widening is a good idea, but not narrowing --- expanding a u8 into a usize doesn't actually lose any information, but going the opposite way does.
- therein 9y ago
  Depends on the machine architecture really but I agree in principle.
Gibbon1 9y ago
> I can’t imagine there are that many places where you’d need to use a u8 as an index I have some firmware on a small machine, there aren't any arrays with more than two dozen elements. On the eight bit machine the the code originally ran on using a 16 or 32 bit int caused a lot of code bloat. You might not think that's a problem but consider the price difference between a processor with 64k of flash and 128k might be a dollar. Times 100,000 units a year. The above is why I'm not going to use rust anytime soon, because a rust binary size is about 4 times larger than C. That would add about $2-3 to the cost of the product. Or $200-300k a year for no real benefit at all.
- burntsushi 9y ago
  That doesn't make any sense. If `i` is a `u8` and `xs` is an array, then `xs[i as usize]` works today. The criticism isn't even specific to exotic environments. The same reasoning applies at bigger widths too. I've certainly used `u32` in places instead of `usize` to avoid doubling the size of my heap use on 64-bit systems. Implicit widening would be nice, but it isn't necessary.
  - Gibbon1 9y ago
    In the firmware I mentioned on an 8 bit system using a 16 bit indx increases the resulting code by 2-3X. A lot of times the code size doesn't matter. In my case it's important. Consider a lowly printf statement in my firmware. It takes about 120 bytes of code. A trivial amount! Lets see how much that costs us. Marginal cost of flash is about $1.00/64k. So 120b/64k X $1 = $0.001875 per unit. We ship 100,000 units per year. So that printf costs $187 per year.
    - burntsushi 9y ago
      I feel like you just repeated your previous comment. I don't need a lesson on unit economics. My whole point is that your don't need a 16 bit index.