Date: Sun, 9 Mar 2025 07:58:14 +0100
> On Mar 7, 2025, at 11:35 PM, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> But there's very good reason to not allow this.
> constexpr function shouldn't be allowed to give different results when called with the same arguments (or no arguments in this case).
I agree that constexpr functions follow this rule when called at runtime. However, I am not so sure about the rules that should be followed at compile time. The constructor of std::vector returns different results even at compile time (different addresses for the allocation). It is kind of mandatory that repeated calls to the constructor yield different results (otherwise we could only use on std::vector (of the same type) inside a compile time function). If constexpr means that the results can be cached this really means that we cannot mark now() as constexpr when called at runtime!
Do we need to specify functions as ‘mutable constexpr’ to denote that they don‘t provide this guarantee? This would be yet another proposal.
>
> But there's very good reason to not allow this.
> constexpr function shouldn't be allowed to give different results when called with the same arguments (or no arguments in this case).
I agree that constexpr functions follow this rule when called at runtime. However, I am not so sure about the rules that should be followed at compile time. The constructor of std::vector returns different results even at compile time (different addresses for the allocation). It is kind of mandatory that repeated calls to the constructor yield different results (otherwise we could only use on std::vector (of the same type) inside a compile time function). If constexpr means that the results can be cached this really means that we cannot mark now() as constexpr when called at runtime!
Do we need to specify functions as ‘mutable constexpr’ to denote that they don‘t provide this guarantee? This would be yet another proposal.
Received on 2025-03-09 06:58:28