4 ms·

A lot of classic c++isms, some good ones. constexpr weirdness is among my top choices

WalterBright 2y ago
> A good way to think about constant expressions is that `constexpr` is a hint that lets the compiler know that the variable or function CAN be evaluated at compile time, but it is not required In D, CTFE (Compile Time Function Evaluation) is guaranteed to run at compile time. CTFE happens whenever there's a constant-expression in the grammar, such as the initialization of an enum: enum A = func(3); func(3) evaluates at compile time.
- bingo3131 2y ago
  Calling it a hint is very much over-simplifying things as there are also restrictions on what a constexpr function is and is not allowed to do, although those restrictions become fewer and fewer as time goes on as compilers are so advanced that they can emulate more system level things at compile time. Also, constexpr on a variable is not a hint - it must be evaluated at compile time, where-as a constexpr function will be evaluated at either compile time or runtime depending on the context and arguments passed to it. For a function that you either want to work at compile time or not at all (compile error), consteval is the hardened version. Yes, sadly this means "constexpr" variables and "consteval" functions must be calculated at compile time, while "constexpr" functions can be used both at compile time and runtime. An annoying distinction.
  - WalterBright 2y ago
    In D, any function can be used to evaluate at compile time. If it is used for a constant-expression and cannot be evaluated at compile time, it is a compilation error. Also, the entire function needn't be evaluatable at compile time - only the path taken through it. Simply no need for tagging them one way or another.
adrian_b 2y ago
I agree, but the "constexpr" weirdness links to a video with a clickbait title. You are expected to watch most of the video, before learning that the purpose of the video is to argue that in almost all cases one should use "static constexpr" and not just "constexpr". The argumentation can be interesting, but it would have been nicer to just state the conclusion from the beginning, allowing a decision of whether it is desirable to spend time to also know the reasons for this.

> A good way to think about constant expressions is that `constexpr` is a hint that lets the compiler know that the variable or function CAN be evaluated at compile time, but it is not required In D, CTFE (Compile Time Function Evaluation) is guaranteed to run at compile time. CTFE happens whenever there's a constant-expression in the grammar, such as the initialization of an enum: enum A = func(3); func(3) evaluates at compile time.

bingo3131 2y ago
Calling it a hint is very much over-simplifying things as there are also restrictions on what a constexpr function is and is not allowed to do, although those restrictions become fewer and fewer as time goes on as compilers are so advanced that they can emulate more system level things at compile time. Also, constexpr on a variable is not a hint - it must be evaluated at compile time, where-as a constexpr function will be evaluated at either compile time or runtime depending on the context and arguments passed to it. For a function that you either want to work at compile time or not at all (compile error), consteval is the hardened version. Yes, sadly this means "constexpr" variables and "consteval" functions must be calculated at compile time, while "constexpr" functions can be used both at compile time and runtime. An annoying distinction.
- WalterBright 2y ago
  In D, any function can be used to evaluate at compile time. If it is used for a constant-expression and cannot be evaluated at compile time, it is a compilation error. Also, the entire function needn't be evaluatable at compile time - only the path taken through it. Simply no need for tagging them one way or another.

adrian_b 2y ago

I agree, but the "constexpr" weirdness links to a video with a clickbait title. You are expected to watch most of the video, before learning that the purpose of the video is to argue that in almost all cases one should use "static constexpr" and not just "constexpr". The argumentation can be interesting, but it would have been nicer to just state the conclusion from the beginning, allowing a decision of whether it is desirable to spend time to also know the reasons for this.