Why is `opequals` for objects not `@safe` by default?

[Liam McGillivray]

If you were willing to do breaking changes, perhaps the base 
`opEquals` function can be set to `@safe`. Of course, that would 
be a breaking change if anyone has an override that isn't 
compatible with `@safe`. However, perhaps there can be a 
deprecation warning for any non-safe code defined inside 
`opEquals`, and then a few years later the base function can be 
declared as `@safe`. Given that `@trusted` exists, this would be 
a very easy fix for anyone to make.

Does it currently work if a `@safe` declaration is added for 
`opEquals`, but no definition? If not I think this should work. 
It would just default to the existing `opEquals` function, but 
with the `@safe` attribute.

Anyway, I discovered that `==` can be replaced with `is`, and it 
seems to do the same thing while working within a `@safe` 
function.

On Friday, 5 April 2024 at 05:56:05 UTC, Jonathan M Davis wrote:
> Ideally, Object wouldn't have functions like opEquals, and 
> they'd only be added by derived classes so that programs could 
> put whatever attributes on them make the most sense, but that's 
> a breaking change, so it hasn't happened.
> - Jonathan M Davis

That sounds like a horrible idea. For something as basic as 
opEquals, one shouldn't need to do an operator override.