Remove &const

[bstrie]

#7342 lamented the lack of a bug for this.

I've heard some concerns raised that there exist scenarios that require &const, and thus it cannot be removed. If you have examples to demonstrate this, please post them here.

[alexcrichton]

From what I understood, &const can and should be removed. On the other hand, it was unclear whether *const could or should be removed just yet.

&const is coercible from &mut and & so I think that the purpose was to define a method on &const and you get an implementation regardless of whether you have a & or &mut pointer. Nowadays, &mut is coercible to & so this is no longer an issue.

As far as I know, *mut is not coercible to * and I'm not sure that it's being planned to be or whether it should be.

[thestinger]

&const is also allowed to alias with &mut because it's more restricted than & reference, I don't have any use cases for that however

[erickt]

I found one situation where it was nice to have &const. I had some code that used to use:

vec::bytes::copy_memory(dst: &mut [u8], src: &const [u8], count: uint)

to blit bytes inside the same vector. This was safe because copy_memory uses memmove, which guarantees it works on overlapping arrays. After b29c368, the src was changed to be &[u8]. This made me change from this code snippet:

let mut data = vec::from_elem(1024, 0u8);
...
vec::bytes::copy_memory(data, data.const_slice(512, 1024), 512);

To

let mut data = vec::from_elem(1024, 0u8);
...
let mut i = 0;
while i < 512 {
    data[i] = data[512 + i];
    i += 1;
}

Because passing an immutable reference and a mutable reference to the same data to a function is rightly an error.

[alexcrichton]

This was completed in 5c35047