Raw pointer coercion

[mahkoh]

*mut T and &mut T should coerce to *const T.

Rendered

[Gankra]

Yes

Thank you

This is a constant source of pain with the ptr API, where the read and copy_memory functions take *const T's. It's 100% safe to do, and shouldn't have any surprising consequences.

[petrochenkov]

+1 (#16926)

[aturon]

Definitely. I doubt that the current behavior is intended.

[aturon]

cc @nikomatsakis @nick29581

[Manishearth]

+1

[nrc]

I was hesitant at first to allow these (philosophically we are dereferencing the raw pointer, which is unsafe, and then referencing with a different raw point), but since we don't actually do a dereference I think they are fine. I have a big RFCs on coercions almost ready which includes this change too.

[ghost]

Counterpoint: remove *const T completely.

Pointers have no semantics, they just point to things. There is no difference between *const T and *mut c_void because they're one transmute away in a block where we need to do it back and forth on every single line. *const T is just a weird crippled *mut T that tries to play with the type system on a level where we've already explicitly thrown away the type system. It tries to force rules on us after we've explicitly told the compiler to let us break all the rules.

Pure Rust does not need it, references work better. C bindings don't need it either, just running bindgen won't give you the full story anyway. A C binding needs the full documentation encoded in a safe interface, not just individual unsafe signatures. *const T has no good reason to exist.

[pnkfelix]

assigning to @nick29581 to shepherd

[ben0x539]

Should we then remove ptr::null() and rename ptr::null_mut() to ptr::null()?

[mzabaluev]

I'm not sure I agree with @Jurily about the need for const raw pointers. Even in C, constness is used as a hint for mutability and ownership transfer, allowing to catch many errors.
That said, I agree that *const T should automatically coerce to *mut T.
On a somewhat related note, was the *const syntax intended or is it just a workaround for the parser?

[ghost]

Rust can express the *const vs *mut difference without the need for language constructs: struct ConstPtr<T>(pub *mut T). This is enough because a *const does not mean the data pointed to is immutable, only that it shouldn't be written through this particular pointer. Just look at how Arena or the slice sorting methods use pointers.

We already need Option for function pointers, and if we really want to write well-typed C bindings, we'd also want things like CArrayPtr, COwnedPtr, CRefCount and strong typedefs for c_int and friends (like when a newbie writes int instead of c_int and it happens to work on their machine, and you still have to read all the headers to figure out whether that's an offset or a bit field).

*const only makes sense for C because that's all they have. Reducing boilerplate for tuple structs would do a whole lot more for Rust than a single arbitrary builtin.

[mahkoh]

I do think it is worth talking about these things, but this particular RFC is just about some very simple and safe additions to the coercion rules.

[mahkoh]

@nick29581: Do you think this RFC needs more details or discussion?

[nrc]

@mahkoh is there anything here that should be added to #401? I think there is an advantage in having this RFC as a separate one if #401 is going to get bogged down in discussion, but that doesn't seem to be the case. Otherwise it seems better to have all the coercion specification in one place.

[mahkoh]

Feel free to add the content of this RFC to #401 if it's not already a superset. There was little debate here regarding the content of the RFC and I believe this RFC could be implemented quickly. There are enormous ergonomics benefits to be had for all those who work with lots of FFI code. Therefore I would appreciate it if this RFC could be merged and implemented quickly, even if it is later superseded by your RFC.

[nrc]

I believe #401 is a strict superset of this one. I'll push this one if it looks like #401 is going to take some time.

[nrc]

#401 has been accepted and I believe includes everything in this one. Closing for now, but if there is anything I've missed and I can re-open