On Thu, Apr 5, 2018 at 9:33 AM, Jason Merrill <ja...@redhat.com> wrote: > 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.
I raised this issue with the C++ committee, and it seems that nobody expects defining a type here to work. So let's go back to your first patch, removing the offending part of semicolon3.C. Jason
