rjmccall added a comment. Right, that's been my thinking, too. The CVR qualifiers are all "view" qualifiers: both the underlying object and the reference to it are assumed to be the same independent of qualifiers, and the qualifiers just affect the rules around accesses. C++'s rules around qualifiers in conversions/casts make sense for view qualifiers, but a lot of our extended qualifiers aren't view qualifiers, so it makes sense that the rules would be different. Conversions between overlapping address spaces make sense to do with `static_cast` (or even an implicit conversion if the source AS is a subset). Conversions between non-overlapping address spaces should probably just not be allowed, honestly, the same way we don't allow conversions between different ObjC ARC qualifiers. There are plenty of less dangerous ways to reinterpret bits if someone's sure they know what they're doing.
In fact, C already formalizes this distinction: `_Atomic` behaves like a qualifier in many ways, but the language doesn't formally consider it one, and part of the reason for that is that it *doesn't* behave like a qualifier in some *other* ways. For example, you cannot convert a `T *` to an `_Atomic(T) *`, and the object representations don't necessarily match. In fact, it's not really true of any of the other qualifiers we support: address spaces, the Objective-C ARC qualifiers, the ptrauth qualifiers that will eventually be upstreamed, etc. , that conversions between overlapping address spaces are more like hierarchy conversions than qualification conversions. The C++ rules around casting qualifiers make sense for the "variant view" qualifiers should be limited to qualifiers should probably be doable with `static_cast`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D151087/new/ https://reviews.llvm.org/D151087 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
