[cfe-dev] [libcxx] Policy with respect to language extensions

[Hal Finkel via cfe-dev]

----- Original Message -----
> From: "Richard Smith" <richard at metafoo.co.uk>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Marshall Clow" <mclow.lists at gmail.com>, "clang developer list" <cfe-dev at lists.llvm.org>, "Gonzalo BG"
> <gonzalobg88 at gmail.com>, "David Majnemer" <david.majnemer at gmail.com>
> Sent: Wednesday, August 12, 2015 7:09:22 PM
> Subject: Re: [cfe-dev] [libcxx] Policy with respect to language extensions
>  
> On Wed, Aug 12, 2015 at 4:01 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
>  
> ----- Original Message -----
> > From: "Marshall Clow" < mclow.lists at gmail.com >
> > To: "David Majnemer" < david.majnemer at gmail.com >
> > Cc: "Richard Smith" < richard at metafoo.co.uk >, "clang developer
> > list" < cfe-dev at lists.llvm.org >, "Gonzalo BG"
> > < gonzalobg88 at gmail.com >
> > Sent: Wednesday, August 12, 2015 5:05:05 PM
> > Subject: Re: [cfe-dev] [libcxx] Policy with respect to language
> > extensions
> > 
> > On Wed, Aug 12, 2015 at 11:32 AM, David Majnemer <
> > david.majnemer at gmail.com > wrote:
> > 
> > 
> > On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <
> > richard at metafoo.co.uk > wrote:
> > 
> > 
> > 
> > I think it would also be useful to have a "strictly conforming" (or
> > as close as we can reasonably get) mode, controlled by a macro.
> > 
> > 
> > Wouldn't we have to be extra careful or we could get ODR violations
> > across object/shared object boundaries if one wanted extra
> > conformance but another did not?
> > 
> > Yes.
> > 
> > 
> > -- Marshall
> 
> Having a macro to control this seems like a recipe for bad things
> (ODR violation being only one problem).
> 
> 
> 
> What sort of actual bad things do you envisage? People will, of
> course, be able to shoot themselves in the foot by having an
> inconsistent definition in different translation units, but we don't
> necessarily need to support that. And it seems like we should be
> able to avoid this having an ABI impact on sane code.

For these particular extensions, I can't say. However, I tend to find the general technique problematic. The issue generally arises for header-only libraries that define (or undefined) these kinds of macros, causing very odd interactions (because such things don't compose). Tracking down why including one library header breaks some other library header because of conflicting desires to define _XOPEN_SOURCE, _GNU_SOURCE, etc. is annoying. Doing the same for features of the C++ standard library that could affect uses of SFINAE, etc., I suspect, would be especially annoying.

 -Hal

> 
> I think the best we can do at this point is have the compiler issue a
> warning in pedantic mode. Maybe we could add some kind of extension
> attribute for this purpose (although we'd need to think carefully
> about when to actually generate the warning - every time some
> extension participates in some overload set might be problematic).
> 
> -Hal
> 
> 
> 
> > 
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> > 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory