6 ms·

A lot of negative comments here but these keywords seem perfectly reasonable to me. If I actually have a place where I'd need them, I'd be able to understand w

A lot of negative comments here but these keywords seem perfectly reasonable to me. If I actually have a place where I'd need them, I'd be able to understand which one to use and why. I like to be able to do more compile-time evaluation and it's definitely a lot less confusing now than abusing templates for that.

kllrnohj 4y ago
Yeah I find these keywords perfectly approachable & straightfoward. I find them easier to understand and rationalize than, say, Kotlin's set of with/let/apply/also/run ( https://kotlinlang.org/docs/scope-functions.html#function-selection https://kotlinlang.org/docs/scope-functions.html#function-se... ) The comments all seem like just mindless anti-C++ circle jerking, with zero relevance to what's actually being discussed in the article. But that's sadly quite common with C++ articles here. If the title has C++, expect to see the same rants regardless of the article.
throwawaymaths 4y ago
Ok but it's 2022 and something like ziglang can do all of these things with two keywords (const and comptime). Why does C++ need four?
- jeffbee 4y ago
  Because of path dependency and backwards compatibility. C++ has 30 years of legacy code to build. Zig doesn't even exist yet; after 6 years it is still in "preview".
- kllrnohj 4y ago
  It looks like in zig all functions are `constexpr` ? As for `constinit`, it looks like ziglang doesn't have an answer for the problem that constinit solves. That is, ziglang appears to have the same bugs here that C++ did before constinit was added.
  - anonymoushn 4y ago
    Can you give an example of a bug in a Zig program caused by the lack of constinit? It seems like Zig just does not have the delayed initialization of static and thread-local variables that C++ has, but I'm not completely sure of this.
    - kllrnohj 4y ago
      Unless I'm misreading this: https://ziglang.org/documentation/master/#Container-Level-Variables https://ziglang.org/documentation/master/#Container-Level-Va... zig has lazily initialized at runtime mutable globals, and compile-time initialized constant globals (so C++'s constexpr variables). But what it doesn't have is compile-time initialized mutable globals (which is what `constinit` does)
      - AndyKelley 4y ago
        // compile-time initialized mutable global: var foo = bar();
        lvass 4y ago
        How does one assert bar() or better yet, an arbitrary expression you place there, is pure?
        anonymoushn 4y ago
        Well, the compiler attempts to evaluate bar(), and if it cannot, you get a compile error
        kllrnohj 4y ago
        > If a container level variable is const then its value is comptime-known, otherwise it is runtime-known. I'm not sure how to reconcile that Zig documentation with your comment's claim. It appears that Zig relies on opportunistic behaviors here instead of contracts. That is, your var foo could be comptime known, but isn't required to be. Which is fine enough, but not comparable to `constinit` either. Alternatively if all container variables are exclusively comptime initialized, then the obvious missing part from Zig would be the inverse of constinit which is the onload initializer behavior.
mhh__ 4y ago
The issue isnt so much where C++ is aiming to go but rather how they're getting there. Consider: C++ let's an increasingly large subset of the language be evaluated at compile. Current endpoint: the whole language will have constexpr everywhere. Correct design: Eagerly try to evaluate everything, ban things that obviously shouldn't or can't be done at compile time.

kllrnohj 4y ago

Yeah I find these keywords perfectly approachable & straightfoward. I find them easier to understand and rationalize than, say, Kotlin's set of with/let/apply/also/run ( https://kotlinlang.org/docs/scope-functions.html#function-selection https://kotlinlang.org/docs/scope-functions.html#function-se... ) The comments all seem like just mindless anti-C++ circle jerking, with zero relevance to what's actually being discussed in the article. But that's sadly quite common with C++ articles here. If the title has C++, expect to see the same rants regardless of the article.

throwawaymaths 4y ago

Ok but it's 2022 and something like ziglang can do all of these things with two keywords (const and comptime). Why does C++ need four?

jeffbee 4y ago
Because of path dependency and backwards compatibility. C++ has 30 years of legacy code to build. Zig doesn't even exist yet; after 6 years it is still in "preview".
kllrnohj 4y ago
It looks like in zig all functions are `constexpr` ? As for `constinit`, it looks like ziglang doesn't have an answer for the problem that constinit solves. That is, ziglang appears to have the same bugs here that C++ did before constinit was added.
- anonymoushn 4y ago
  Can you give an example of a bug in a Zig program caused by the lack of constinit? It seems like Zig just does not have the delayed initialization of static and thread-local variables that C++ has, but I'm not completely sure of this.
  - kllrnohj 4y ago
    Unless I'm misreading this: https://ziglang.org/documentation/master/#Container-Level-Variables https://ziglang.org/documentation/master/#Container-Level-Va... zig has lazily initialized at runtime mutable globals, and compile-time initialized constant globals (so C++'s constexpr variables). But what it doesn't have is compile-time initialized mutable globals (which is what `constinit` does)
    - AndyKelley 4y ago
      // compile-time initialized mutable global: var foo = bar();
      - lvass 4y ago
        How does one assert bar() or better yet, an arbitrary expression you place there, is pure?
        anonymoushn 4y ago
        Well, the compiler attempts to evaluate bar(), and if it cannot, you get a compile error
      - kllrnohj 4y ago
        > If a container level variable is const then its value is comptime-known, otherwise it is runtime-known. I'm not sure how to reconcile that Zig documentation with your comment's claim. It appears that Zig relies on opportunistic behaviors here instead of contracts. That is, your var foo could be comptime known, but isn't required to be. Which is fine enough, but not comparable to `constinit` either. Alternatively if all container variables are exclusively comptime initialized, then the obvious missing part from Zig would be the inverse of constinit which is the onload initializer behavior.

mhh__ 4y ago

The issue isnt so much where C++ is aiming to go but rather how they're getting there. Consider: C++ let's an increasingly large subset of the language be evaluated at compile. Current endpoint: the whole language will have constexpr everywhere. Correct design: Eagerly try to evaluate everything, ban things that obviously shouldn't or can't be done at compile time.