> On Feb 9, 2017, at 6:55 PM, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
> On 9 February 2017 at 23:25, Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
>> On 02/09/2017 11:59 PM, Jonathan Wakely wrote:
>>> It's become apparent that the feature-test recommendations for
>>> features such as std::string_view, std::variant and std::optional are
>>> not sufficient.
>>>
>>> SD-6 says that to check for std::variant you should use
>>> __has_include(<variant>).
>>
>> My gut reaction to this issue is
>> "can't we make __has_include return false if #including
>> the header doesn't actually provide the facility"?
>
> Do you mean some way for a header to inform the preprocessor that
> although it exists as a file on disk, it should be ignored? That might
> be nice, although non-trivial to implement. The preprocessor might
> have to open the file, do some basic preprocessing (so that macros
> such as __cplusplus and __linux__ and __x86_64__ can be tested in
> preprocessor conditions) and check what happens. Either an #error or
> some implementation-defined #pragma could make __has_include return
> false. That would be a significant change to __has_include, which
> currently doesn't need to open the file.
>
> Maybe compilers could deal with it in non-standard ways, so that if
> the first line of the header contains some #pragma the __has_include
> is false (so the whole file doesn't need to be preprocessed) For
> example:
>
> #pragma GCC has_include(__cplusplus >= 201402L)
>
> That could cause __has_include to return the result of the expression
> (converted to either 0 or 1, in case somebody uses an expression that
> has some other non-zero value).
>
> I originally thought about a __try_include feature, that would attempt
> to include the header and if either evaluate to 1 on success, or 0 if
> there was an error (either finding the header, or processing it). That
> could also be non-trivial to implement though, if for example the
> header does:
>
> #define SOME_MACRO 1
> #error "blah blah"
>
> Would the macro remain defined after an unsuccessful __try_include ?
>
> If not it might be unpopular with preprocessor implementors. If yes
> ... it's nasty, but maybe we could say it's unspecified whether any
> macros get defined by a failed __try_include. That seems really nasty
> though. The error could be in a header included indirectly, after
> several other files have been included and liberally defined their own
> macros.
>
>
>> (I would also be happy if "#include <variant>" would simply
>> be an error in older modes, although I do agree the gcc
>> error message is helpful.)
>
> I thought about proposing a change to the GCC compiler that would
> hardcode the __has_include result for standard header names, so it
> would be false in C++14 mode, but that might prevent users from
> supplying their own <variant> that works in C++14 (technically it's
> undefined to give an include file the same name as a standard header,
> but in C++14 <variant> isn't a standard header, so it's OK for users
> to use).
>
> Adding extra __cpp_lib_xxx macros to SD-6 seemed the simplest
> approach, and requires the least work from implementors.

This seems like the best approach to me.

John.

>
> But if people would rather I try to solve this in libstdc++ I can talk
> to the GCC folks about the #pragma idea, or something like that (and
> then hope that Intel and Clang and others to support it too).
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features