On 16 July 2016 at 18:38, Ville Voutilainen <ville.voutilai...@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.
