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

[Eric Fiselier via cfe-dev]

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.


>
> 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.


> Please let me know if there are any strong objections to this plan.
>
> Thanks,
> --dlj
>
> _______________________________________________
> 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/20171011/d38094fa/attachment.html>