[cfe-dev] [libc++] RFC: adding a configuration option to enable constexpr constructors in c++1[xy]

[David Jones via cfe-dev]

On Wed, Oct 11, 2017 at 6:11 PM, Eric Fiselier <eric at efcs.ca> wrote:

>
>
> On Wed, Oct 11, 2017 at 6:30 PM, David Jones via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hello,
>>
>> I'm currently working on migrating a large (100M+ LOC) C++ codebase to
>> libc++. One particular pain point are the absence of constexpr constructors
>> for std::pair, std::array, and std::tuple under C++11.
>>
>
> Nit: std::array shouldn't have any constructors. But the other members are
> conditionally constexpr.
>
>
>> Some older versions of libstdc++ expose constexpr constructors under
>> C++11, while libc++ does not; this causes build failures when using libc++.
>>
>
> Hmm, just to clarify, it's not just older versions of libstdc++ that do
> this, but newer ones as well. It's not like they removed it later.
>
>
>>
>> I would like to add a configuration variable that enables the constexpr
>> qualifier on these constructors for C++11 or later, with the intent of
>> advancing the C++ version as quickly as possible. Most of the uses can be
>> trivially replaced by removing constexpr or switching to arrays, but this
>> is churn for code which will (hopefully) soon be compliant anyhow.
>>
>
> I'm actually quite sympathetic to enabling this extension by default,
> since MSVC and libstdc++ both seem to. We're the odd man out.
> If everybody else can safely get away with this, we should be able to as
> well.
>
> BTW, by "C++11 or later" you mean "C++11" because they're already required
> to be constexpr in C++14.
>

Naturally, yes... although what I really wanted to get at was "not C++03 or
earlier."


>
>
>>
>> I suspect this may be useful for other codebases that build in C++11 mode
>> to move to libc++... however, this would be a non-conforming extension.
>> Adding a configuration option in __config_site.in (with the default
>> being conforming behaviour) seems like it may be the most reasonable way to
>> add the option.
>>
>
> The extension is technically slightly worse than non-conforming; it's
> explicitly forbidden. Implementations are not allowed to apply constexpr
> where it isn't specified. However I think this rule should be relaxed to
> allow implementations to backport newly added constexpr specifiers to older
> dialects as an extension, as is this case.
>
> However my main concern with this as an on-by-default extension is that it
> has the potential to break code. There are certain constexpr evaluations
> that might result in a hard compile error that wouldn't before. I think
> Clang has fixed most of these cases though.
>
>
Right... I think on-by-default might be a bit too much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171011/e9dc50ee/attachment.html>