both halves of the name are problematic, and i think anyone proposing an alternative that still calls it "safety" needs to think it over a bit longer.
"trait object" does make some sense[1] (it is an object in several senses of the word), however "safe" is needlessly confusing, expecially considering "unsafe trait" is a thing that exists. a trait can be unsafe to implement, with both safe and unsafe methods, and be object safe. that's 3 orthogonal concepts using similar terminology.
although i'm sure enough bikeshedding could reveal a name that makes at least a bit more sense âŠī¸
I would like to corroborate as a Rust user by saying that reading this thread is the first time I actually feel I understood what "Object Safe" actually means.
I have never understood the term before and the use of the word "safe" and use of bold "not" in documentation really made it seem like whatever it was, it could blow up in my face and it would be my fault. Safety in Rust documentation had always meant things the users needs to be very careful about or they could break Rust's expectations and lead to UB. Which after readings this thread seems to have been a mistaken impression.
I feel like just updating the documentation text on relevant traits from "This trait is notobject safeâ to simply be more descriptive, like "This trait cannot be used as a trait objectâ or "This trait is notobject safe so cannot be used together with the dyn keyword" would have helped me a lot and does not even require a change in terminology. Expanding the documentation should probably be prioritised higher than changing terminology.
I still think it's a good idea to get rid of the word "safety" as it already has a different meaning for Rust users. I really like dyn-compatible/dyn-compatibility. I also thought up dyn-instantiable/dyn-instantiability, though compatibility might be better.