6 ms·

> That this fails might come as a surprise to a lot of folks because it's easy for a human to see that it's perfectly safe. So what's still unclear to me is,

> That this fails might come as a surprise to a lot of folks because it's easy for a human to see that it's perfectly safe. So what's still unclear to me is, is this failing in the borrow checker "by design", or is it something that will be "improved"? Also, _why_ does it fail in the borrow checker? Is it correct that it fails, or is it a deficiency of the current borrow checker?

gcp 10y ago
It's a limitation of the current borrow checker.
- Diggsey 10y ago
  It would be relatively easy to overcome this limitation, but it would involve making slices "special" to the compiler, which also means another special rule for the programmer to use. It would be preferable if you could make your own slice-like types which supported indexing, but to do that you need a mechanism to tell the compiler that your `IndexMut` implementation returns disjoint references for different indices, and that requires a mechanism for the compiler to determine whether two indices are the same (in case your indices are not integers).
burntsushi 10y ago
If "correct" corresponds to "if and only if safe," then no, it's not correct because the code I posted in my previous comment is safe, but the borrow checker rejects it. I only posted samples to demonstrate working with the borrow checker. Think about this code: let mut owned = vec![1, 2]; let x = &mut owned[i]; let y = &mut owned[j]; What are the values of `i` and `j`? If they are equivalent, then this code is unsafe, because it would permit mutable aliases. Therefore, the borrow checker would need to prove something about what values of `i` and `j` are legal at this particular point in the program. (Errmmm, dependent types anyone?) With that said, if you do have code like my original sample (where the indices are constants and trivially not equal), then perhaps it would be reasonable to say that is a deficiency of the borrow checker as it currently exists that could be feasibly fixed. It's not clear what the impact of fixing that deficiency would be. For example, I don't think it would have made the OP's life any better.
- mkawia 10y ago
  When in doubt be extra safe.
  - sh_tinh_hair 10y ago
    I guess that is equivalent to 'if it might be broke, break it'?
    - Ygg2 10y ago
      Let's see, you can be extra safe and deny certain programs. Or be more "free", and break code when you introduce safer borrow checker. It would literally break forward compatibility.
      - sh_tinh_hair 10y ago
        You know I really don't care for a pl that tells me how to do things. I fought python for a long time on a simple issue like indentation. C like syntax is best. RUST is stupid syntactically...surely you've noticed it's a leap. I'd use limbo before Rust.
GolDDranks 10y ago
It's a limitation of the borrow checker, but it's more of a limitation of simple, orthogonal design than a hard technical limitation of the implementation. It could have special cases for many things, such as letting the disjoint indexes pass. But that would be a special case because it can't always prove that the indexes are disjoint. So it leaves up to libraries to provide APIs that do that. This is why `split_at_mut()` demonstrated in grandparent post exists.

gcp 10y ago

It's a limitation of the current borrow checker.

Diggsey 10y ago
It would be relatively easy to overcome this limitation, but it would involve making slices "special" to the compiler, which also means another special rule for the programmer to use. It would be preferable if you could make your own slice-like types which supported indexing, but to do that you need a mechanism to tell the compiler that your `IndexMut` implementation returns disjoint references for different indices, and that requires a mechanism for the compiler to determine whether two indices are the same (in case your indices are not integers).

burntsushi 10y ago

If "correct" corresponds to "if and only if safe," then no, it's not correct because the code I posted in my previous comment is safe, but the borrow checker rejects it. I only posted samples to demonstrate working with the borrow checker. Think about this code: let mut owned = vec![1, 2]; let x = &mut owned[i]; let y = &mut owned[j]; What are the values of `i` and `j`? If they are equivalent, then this code is unsafe, because it would permit mutable aliases. Therefore, the borrow checker would need to prove something about what values of `i` and `j` are legal at this particular point in the program. (Errmmm, dependent types anyone?) With that said, if you do have code like my original sample (where the indices are constants and trivially not equal), then perhaps it would be reasonable to say that is a deficiency of the borrow checker as it currently exists that could be feasibly fixed. It's not clear what the impact of fixing that deficiency would be. For example, I don't think it would have made the OP's life any better.

mkawia 10y ago
When in doubt be extra safe.
- sh_tinh_hair 10y ago
  I guess that is equivalent to 'if it might be broke, break it'?
  - Ygg2 10y ago
    Let's see, you can be extra safe and deny certain programs. Or be more "free", and break code when you introduce safer borrow checker. It would literally break forward compatibility.
    - sh_tinh_hair 10y ago
      You know I really don't care for a pl that tells me how to do things. I fought python for a long time on a simple issue like indentation. C like syntax is best. RUST is stupid syntactically...surely you've noticed it's a leap. I'd use limbo before Rust.

GolDDranks 10y ago

It's a limitation of the borrow checker, but it's more of a limitation of simple, orthogonal design than a hard technical limitation of the implementation. It could have special cases for many things, such as letting the disjoint indexes pass. But that would be a special case because it can't always prove that the indexes are disjoint. So it leaves up to libraries to provide APIs that do that. This is why `split_at_mut()` demonstrated in grandparent post exists.