I don't think we should use place in suggestions.

You should use an unsafe block inside the function, even if this is an unsafe function, as this example will warn in edition 2024:

warning[E0133]: dereference of raw pointer is unsafe and requires unsafe block
 --> t.rs:4:5
  |
4 |     *oldvalue = "New Value".to_owned();
  |     ^^^^^^^^^ dereference of raw pointer
  |
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/unsafe-op-in-unsafe-fn.html>
  = note: raw pointers may be null, dangling or unaligned; they can violate aliasing rules and cause data races: all of these are undefined behavior
note: an unsafe function restricts its caller, but its body is safe by default

Right now, this text does not clearly acknowledge that “the value is always initialized (and so the code is correct)” is a possible case. I worry that people will take it as “plain assignments are always bad style”, and possibly rewrite correct code into code that forgets instead of dropping (or add needless oldvalue_is_initialized flags, or just take away “sheesh, Rust has things that are broken by default”). I think it would be significantly better if the text and examples gives a concrete recommendation for the case where the pointer is initialized.

The obvious concrete recommendation to make is “allow/expect the lint”, but in some cases, converting back to safe &mut could be better, allowing the unsafe to be more narrowly scoped — I’m particularly thinking of cases where raw pointers are being used to perform borrow splitting that can’t be checked by the borrow checker, where it makes sense to convert to &mut as soon as the splitting is done, but before the actual writes happen.

My initial impression when I read through this and #4294 was that the recommended way to resolve this is to simply always use ptr::write() (+ ptr::drop_in_place if what the user wrote is really what they want - the user can then addditonally justify that dropping is indeed the correct thing to do by writing a safety comment which can be enforced by other lints, and is then no longer hidden behind the = operator). So if the value is initialized, write ptr.drop_in_place(); ptr.write(value);.

This is also how I understood the help messages:

   = help: use `std::ptr::write()` to overwrite a (possibly uninitialized) place
   = help: use `std::ptr::drop_in_place()` to drop the previous value if such value exists

I feel like recommending to allow the lint in the case that the code is correct goes against what the help messages are saying?

I have two thoughts on this, which are:

1. Verbosity is not necessarily clarity. Splitting a single assignment into separate drop_in_place() and write() calls:

   • Creates a hazard, in that if they end up with some other code inserted in between them, that code is executing with a sort of broken invariant that might be overlooked:

     ptr::drop_in_place(self.ptr);
     ptr::write(self.ptr, self.compute_new_value()); // compute_new_value could see a deinited *self.ptr!

   • Makes it look like something more esoteric than an ordinary Rust assignment to an initialized place in safe code.

   I could get behind “you should convert the pointer to &mut before assigning”, which makes it clear that the invariants of &mut (initialization, exclusive access) apply, but “implement the two parts of assignment yourself just so you’re being explicit” feels like imposing a lot of mental cost for the sake of “code that is doing something else than what this code is doing might be doing something wrong”.

2. If this lint is proposing never assigning through a raw pointer, that feels rather like it is saying “don't use this part of the language at all!” recommendation, which — if Clippy is doing something like that outside of restriction lints, then it feels like something has gone wrong at the language-design level. Rust shouldn’t have (non-deprecated) features that are always wrong to use.

   And perhaps this feature should be deprecated, but in that case, it's time to talk to T-lang, not just add a lint.