On Wed, Apr 4, 2018 at 12:25 PM, Alexandre Oliva <aol...@redhat.com> wrote: > On Apr 4, 2018, Jason Merrill <ja...@redhat.com> wrote: > >> On Tue, Apr 3, 2018 at 11:25 PM, Alexandre Oliva <aol...@redhat.com> wrote: >>> I still think we could attempt to retain the extension as it is, parsing >>> types introduced in data member initializers within the scope of the >>> class containing the data member, like we do, but, when the class is >>> already complete, recording it if not in TYPE_FIELDS, in some additional >>> field consulted for name mangling purposes and, in order to retain >>> compatibility, if the type is not a closure or anonymous, also recording >>> it in the enclosing namespace, so that it is found by lookup as in the >>> quoted snippet. >>> >>> Is that a terrible idea? > >> It sounds like a lot of work to support a very questionable pattern. > > It's not so much work (the simple patch below does just that, and its > testing is almost done); I agree it's questionable, and it's limited (it > never worked in initializers of members of template classes, as the -4 > testcase, so we don't have to worry about retaining temporary > compatibility with that), but it's there, so I think we'd be better off > deprecating it, if that's the direction we want to go. The patch below > has just the right spot for a deprecation warning, even ;-) > > We could recommend users to use a closure that returns the offsetof > instead of the unadorned offsetof. That would work portably, but we > shouldn't make the transformation ourselves: it would change the > ABI-defined numbering of closure types. > >> Perhaps we should just disallow defining a type in offsetof if the >> current scope is a class. > > Even anonymous types? I suspect this could break a lot of existing > code, with anonymous types hiding in macros.
It seems unlikely to me that such a use of macros would occur at class scope; there's no C compatibility issue there. Jason
