[PATCH] D86354: [ADT] Make Optional a literal type.

David Zarzycki via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 27 04:02:29 PDT 2020


davezarzycki added a comment.

In D86354#2240009 <https://reviews.llvm.org/D86354#2240009>, @dblaikie wrote:

> In D86354#2240001 <https://reviews.llvm.org/D86354#2240001>, @varungandhi-apple wrote:
>
>>> This seems to only allow empty optionals to be constexpr. Should the non-default constructor also be constexpr?
>>
>> The reason I implemented the minimal thing was that I wasn't sure how far I should go. In a Swift PR <https://github.com/apple/swift/pull/33118#issuecomment-668818658>, @davezarzycki raised the point about `constexpr` potentially leading to longer compile times even when not used for compile-time computation. I asked some folks internally at Apple and the response I got was along the lines of, "That's surprising... If that's actually the case, it should be reported as a Clang bug". I haven't been able to dedicate time to benchmarking the impact of `constexpr` on compile time... Since `Optional` is a currency type, I wasn't sure if people would object to more methods being marked constexpr. In principle, I don't see any reason for any method on `Optional` to not be constexpr.
>
> That upstream thread doesn't look like it's talking about the impact of constexpr in non-constexpr contexts. Yes, making a variable constexpr when you don't need it to be can have negative compile time consequences - but in Clang I don't believe (again, can be bugs, but it doesn't sound like that swift thread is suggesting the existence of such bugs) a constexpr function called in a non-constexpr context is handled any differently than if it were a non-constexpr function. (GCC is different in this regard and does try to do constexpr things in non-constexpr contexts, though unclear how hard it tries before bailing out to the non-constexpr handling)

Actually, I was concerned about `constexpr` affecting non-constexpr contexts. Perhaps it was the gcc behavior that this former coworker was worried about (and I wish I remember who told me this so I could ask them but alas this feedback was many years ago). I'm happy to learn that clang isn't trying to be clever about evaluating constexpr in non-constexpr contexts.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86354/new/

https://reviews.llvm.org/D86354



More information about the llvm-commits mailing list