This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add constexpr to iterator adaptors, array and range access
- From: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- To: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "libstdc++" <libstdc++ at gcc dot gnu dot org>, Daniel Krügler <daniel dot kruegler at gmail dot com>
- Date: Sat, 16 Jul 2016 18:52:03 +0300
- Subject: Re: [PATCH] Add constexpr to iterator adaptors, array and range access
- Authentication-results: sourceware.org; auth=none
- References: <CAFk2RUYoR8dGZCyb+y7aFUKHccf7LA1ZorJ_Y7z+jnmpdcJ6-w@mail.gmail.com>
On 16 July 2016 at 18:38, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> I think it's reasonable to make the functions constexpr even when the standard
> doesn't allow it, and if c++17 allows them to be constexpr, make the functions
> constexpr in other standard modes as well. We could of course ask whether
> LWG thought about applying the changes to previous standards or not.
Let me elaborate a bit. I think it's perfectly sane to enable
constexpr for c++11 and c++14
when c++17 enables it, and talk to other vendors and LEWG/LWG about syncing such
changes.
>> How strict do we want to be about obeying the "implementors can't add
>> constexpr" rule in these cases?
>
> I'd rather not be strict.
..and here I would prefer accepting some amounts of non-compliance and
feeding the results
back to LEWG/LWG and other vendors. If/when users run into trouble, we
get better constexpr
support in the spec, and we gain better performance for cases where
constexpr evaluation
isn't strictly required.
I have had some ruminations for an annotation of some kind that would
allow the front-end to detect non-portable
uses of constexpr but allow the performance increase for portable
cases. I haven't had the time
to do the actual work for the front-end to be able to tell the
difference based on such an annotation.