Hacker News Reader

Comment by zarzavat | Hacker News Reader

It's not the same. e.g.

   const int x = readInput();

cannot be constexpr. Consider constexpr as a compile time assertion that a given symbol is available at compile time. If you didn't have the constexpr keyword then you would have have to inspect the definition to determine that every subexpression is constexpr.

View on HN

Why not

  const int x = const foo(bar(y));

?

The compile can (and will) do that at run time, it just won't let the code alter x afterwards (either at compile time or run time)

You should check Zig comptime keyword, which does exactly that. Its the feature from zig I miss the most in C.

That sounds like a subset of EVAL-WHEN[1].

[1] http://clhs.lisp.se/Body/s_eval_w.htm

"inspect the definition"

Yes, that's what I meant with "the compiler can do it".

Not given C and C++ separate file compilation.

That might be OK in an IDE driven language such as Java, but I doubt the neckbeards writing C in a plain text editor would go for that level of implicitness. In C++ it might be more acceptable since you practically need an IDE since C++11 to resolve all the auto type inference.

C neckbeard here. I do fully hope and expect and assume the compiler to fold constants and figure out as much at compile time as it can. This is the kind of optimization that doesn't make the code harder to reason about, even when coding with ed, since the logic and ultimate result of these expressions does not change.

Heavy type inference, overloading, and inheritance are a completely different beast and they make the code a lot more opaque.

Reply on news.ycombinator.com