rsmith added a comment. In D63451#1549563 <https://reviews.llvm.org/D63451#1549563>, @rjmccall wrote:
> Can this attribute not be applied to a base class, or to a type? The standard attribute forbids that right now. We could add a custom attribute that permits it, but we're required to diagnose application of the standard attribute to a type -- though a warning would suffice to satisfy that requirement. (Because this gives "same as a base class" layout, adding it to a base class wouldn't have any effect right now, but we could certainly say that the attribute on a class type also implies the class is not POD for the purpose of layout, to permit tail padding reuse.) > I think every time I've seen someone get bitten by the unique-address rule, > it was because they had a base class that deleted some constructors (or > something like that) and which was a base of a million different types; I'm > sure the language model they'd prefer would be to just add an attribute to > that one type instead of chasing down every place where they declared a field > of the type. The place where we expect this to be used is where a class template wants to store a copy of some user-provided type that may well be empty (eg, an allocator, a comparator, that kind of thing). There are probably more producers of such types than consumers, so putting the attribute on the consumer seems to make some sense (though it really could go in either place, and both probably have reasonable use cases). I'd be happy to go back to the committee with a proposal to extend this attribute to also apply to classes if you can provide a few convincing examples. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63451/new/ https://reviews.llvm.org/D63451 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
