[cfe-dev] Improving diagnostics when moving standard library headers

[David Blaikie via cfe-dev]

Fair enough - yeah, I'd lodge a relatively uninformed vote for keeping
experimental/optional available to C++14 users - but I don't really know
the details of the wording for experimental, cost involved in doing so, etc.

On Fri, Aug 10, 2018 at 8:32 AM Louis Dionne <ldionne at apple.com> wrote:

> Actually, the problem is deeper than this. Since we removed support for
> <experimental/optional> completely and <optional> is only provided in C++17
> and above, we created a hole for users that want <optional> in C++14. They
> just can’t get it anymore, whereas previously they would have used
> <experimental/optional>. As much as I hate to say this, I think the answer
> to this question is just “you’re using experimental features, sorry if they
> go away.” Or, alternatively, we could keep providing
> <experimental/optional> in C++14 mode.
>
> Given that the nature of the problem is different than what I initially
> thought, I don’t think it is worth pursuing any kind of compiler change to
> enable what I talked about in the original message.
>
> Louis
>
>
> On Aug 10, 2018, at 11:25, David Blaikie <dblaikie at gmail.com> wrote:
>
> Why would the user write the code in that way, though? Wouldn't they want
> "has_include optional, include optional, else include
> experimental/optional"? to prefer the final/standardized version
>
> On Thu, Aug 9, 2018 at 8:13 AM Louis Dionne via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> In libc++, we moved the <experimental/optional> header to <optional>. To
>> guide users when they try to use <experimental/optional>, that file now
>> contains:
>>
>>     #error "<experimental/optional> has been removed. Use <optional>
>> instead."
>>
>> The problem is that it traps people using
>> __has_include(<experimental/optional>) to detect whether they should be
>> using std::experimental::optional or std::optional on the version of the
>> standard library they're using. For example:
>>
>>     #if __has_include(<experimental/optional>)
>>     #   include <experimental/optional>
>>     #else
>>     #   include <optional>
>>     #endif
>>
>> This is currently always broken, since <experimental/optional> is always
>> provided, but including it is an error.
>>
>> I believe a better situation would be to remove the header, but somehow
>> have a way of providing a better compiler diagnostic than the default one
>> when that header is included. The default diagnostic will just say “I can’t
>> find this header!”, whereas we really want to say "This header has been
>> moved over there". Ideally, this sort of feature would also be usable by
>> other libraries, not just the standard library, but I’d welcome just about
>> any solution for now.
>>
>> My question: Do we have a way of achieving what I'm requesting today? If
>> not, does anyone have ideas about how to achieve this? My guess is that a
>> pragma in the header that's been moved would not work, because that means
>> __has_include would have to know way more than it probably does today.
>>
>> Thanks,
>> Louis
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180810/c0bfdcc1/attachment.html>