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

Wed Aug 26 12:47:30 PDT 2020

dblaikie added a comment.

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)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86354