mboehme added a comment. In D114235#3340412 <https://reviews.llvm.org/D114235#3340412>, @erichkeane wrote:
> In D114235#3340369 <https://reviews.llvm.org/D114235#3340369>, @mboehme wrote: > >> In D114235#3244054 <https://reviews.llvm.org/D114235#3244054>, >> @aaron.ballman wrote: >> >>> so there could likely be places that need updating to look "through" the >>> attributed type. But unlike with arbitrary plugins, the number of places is >>> hopefully more reasonable. >> >> IIUC, this already happens to some extent for other type attributes -- >> correct? For example, the nullability attributes (`_Nonnull` and the like). >> However, these can only be applied to pointer types (e.g. `int * _Nonnull >> ptr`), while an `annotate_type` attribute could also be applied to other >> types (e.g. `int [[clang::annotate_type("foo")]] i`). Is this an example of >> the places you're thinking of that would need to be touched? > > _Nonnull has exactly the problems we are talking about; it is put on the > attributed-type, which end up getting lost in canonicalization just about > immediately. For my purposes, it would be fine, and maybe even desirable, for the proposed `annotate_type` to have the same limitations as `_Nonnull`. Are you saying that a) this would not be acceptable for a more general-purpose attribute such as a putative `annotate_type`, or even that b) the behavior of `_Nonnull` itself is seen as undesirable and should be changed if possible? > This is going to be an incredibly heavy lift, I just don't see how you can > make it 'last' through the type system. For example: > > template<typename T> > struct S { > using my_type = T; > }; > > using my_attr_type = int [[annotated_type("asdf")]]; > > S<int>::my_type; > S<my_attr_type>::my_type; <-- will have lost the attribute already, since > you want them to behave as the same type. > std::is_same<int, my_attr_type>::value; // Do you want this to be true? Yes. > std::is_same<S<int>, S<my_attr_type>::value; // What about this one? Yes. Both of these are what the `_Nullable` attribute does today (godbolt <https://godbolt.org/z/Tv3GeWefh>), and I would be happy for the proposed `annotate_type` attribute to have the same semantics. > This problem ends up being generally intractable as far as I can imagine. > The C++ language doesn't have the idea of strong-typedefs, a type is just the > type. You can't have 1 instance of the type have an attribute, and others > not without them being DIFFERENT types. So you'd have to have some level of > AnnotatedType in the type system that does its best to ACT like its > underlying type (at great development cost to make sure it doesn't get lost, > basically everywhere), but actually isn't. For example, it would have to end > up failing the 2nd `is_same` above, which, IMO, would be language breaking > unless the 1st `is_same` ALSO stopped being true. As noted above, this isn't actually what I'm trying to achieve. Some colleagues and I are currently preparing an RFC for the specific use case we'd like to use the proposed `annotate_type` attribute for. That use case might give more context to the discussion. If you think it would help to put this discussion on hold until we've written up and posted the RFC, I'd be happy to do that. If you have any additional comments right now, I'd be happy to hear those too of course! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D114235/new/ https://reviews.llvm.org/D114235 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
