4 ms·

D initializes all variables. If you don't provide an initializer, the compiler inserts the default initializer for it. But if you really, really want to leave

D initializes all variables. If you don't provide an initializer, the compiler inserts the default initializer for it. But if you really, really want to leave it uninitialized, write: int x = void; where you're not writing that by accident.

Negitivefrags 7mo ago
That is a way better syntax. I wonder why C++ didn't adopt it.
- jcalvinowens 7mo ago
  There's a whole section on that: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795r5.html#optout-alts https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...
  - WalterBright 7mo ago
    I don't understand its claim of a "self-documentation trap". I'm surprised the "= void;" wasn't discussed. People liked it immediately in D, and other alternatives were not proposed.
    - saagarjha 7mo ago
      The syntax is probably fine but I feel that the default kind of sucks; default initialization has mostly fallen out of favor these days.
- bluGill 7mo ago
  Because you can't adopt that syntax after the fact. there is 30 years of C++ in the real world, initializing everything by default unless you opt-in will break some performance critical code that should not initialize everything (until it is updated manually - it has to be manual because tools are not smart enough to know where something was intentionally not initialized 100% of the time) Thus the current erroneous. It means this isn't a bug (compilers used to optimized out code paths where an uninitialized value is read and this did cause real world bugs when it doesn't matter what value is read). It also means the compiler is free to put whatever value they want there - one of the goals was the various sanitizers that check for using uninitialized values need to still work - the vast majority of the time when an uninitialized value is read that is a bug in the code. There are a lot of situations where a compiler cannot tell if a variable would be used uninitialized, so we can't rely on compiler warnings (it sometimes needs solving the halting problem).
  - tialaramex 7mo ago
    > There are a lot of situations where a compiler cannot tell if a variable would be used uninitialized, so we can't rely on compiler warnings (it sometimes needs solving the halting problem). It's an explicit choice in C++ to always accept correct programs (the alternative being to always reject incorrect programs†). The committee does not have to stick by this bad decision in each C++ version, of course they aren't likely to stop making the same bad choice, but it is possible to do so. If you're allowed to take the other side, you can of course (Rust and several other languages do this) reject programs where the compiler isn't satisfied that you definitely always initialize the variable before it's value is needed. Most obviously (but it's pretty annoying, so Rust does not do this) you could insist on the initialization as part of the variable definition in the actual syntax. † You can't have both, by Rice's Theorem, Henry Rice got his PhD for figuring out how to prove this, last century, long before C++ was conceived. So you must pick, one or the other.
  - aw1621107 7mo ago
    > there is 30 years of C++ in the real world, initializing everything by default unless you opt-in will break some performance critical code that should not initialize everything ...But the change to EB in this case does initialize everything by default?
    - bluGill 7mo ago
      No it doesn't. It says the value is unspecified but it exists. Sometimes some compilers did initialize everything (this was common in debug builds) before. Some of them will in the future, but most won't do anything difference. The only difference is some optimizer used to eliminate code paths where they could prove that path would read an uninitialized variable - causing a lot of weird bugs in the real world.
      - aw1621107 7mo ago
        > It says the value is unspecified but it exists. The precise value is not specified, but whatever value is picked also has to be something that isn't tied to the state of the program so some kind of initialization needs to take place. Furthermore, the proposal explicitly states that (some) variables are initialized by default: > Default-initialization of an automatic-storage object initializes the object with a fixed value defined by the implementation > The automatic storage for an automatic variable is always fully initialized, which has potential performance implications. > The automatic storage for an automatic variable is always fully initialized, which has potential performance implications.
tialaramex 7mo ago
> If you don't provide an initializer, the compiler inserts the default initializer for it. This requires that there is a default. Several modern languages (such as Go) insist on this, it means now your types don't even model reality in this very fundamental way. Who is a person's default spouse? Even where you can imagine a default it's sometimes undesirable to have one, for example we already live in a society where somebody decided default gender is male - and it might look too much like real data, default birthday being 1 January also matches hundreds of thousands of Americans... The most likely place you go after "Everything has a default" is the billion dollar mistake because you're inclined to just incorporate "or it's default invalid" into the type definition to get your default, and when you do that everywhere needs to have "check it's valid" code added, even if we already just checked that a moment ago.
- kwsp 7mo ago
  I don’t care that much about everything having a default (although it’s nice), but if a language insists on a default value for every type for safety, can’t you just use std::optional?
  - tialaramex 7mo ago
    I can't tell if you imagine std::optional is a value (it is not) or if you know it's a templated type but you imagine that somehow it would be OK to redefine all programs so that every type is std::optional<T> of that type instead so as to simplify initialization. Either way no, that can't work.
    - MaxBarraclough 7mo ago
      > Either way no, that can't work. Kotlin has explicit nullable types. Rust has no null, but has option types. Both languages work fine. I think your point was that neither approach could reasonably be retrofitted to C++, do I have that right?
      - tialaramex 7mo ago

Negitivefrags 7mo ago

That is a way better syntax. I wonder why C++ didn't adopt it.

jcalvinowens 7mo ago
There's a whole section on that: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795r5.html#optout-alts https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...
- WalterBright 7mo ago
  I don't understand its claim of a "self-documentation trap". I'm surprised the "= void;" wasn't discussed. People liked it immediately in D, and other alternatives were not proposed.
  - saagarjha 7mo ago
    The syntax is probably fine but I feel that the default kind of sucks; default initialization has mostly fallen out of favor these days.
bluGill 7mo ago
Because you can't adopt that syntax after the fact. there is 30 years of C++ in the real world, initializing everything by default unless you opt-in will break some performance critical code that should not initialize everything (until it is updated manually - it has to be manual because tools are not smart enough to know where something was intentionally not initialized 100% of the time) Thus the current erroneous. It means this isn't a bug (compilers used to optimized out code paths where an uninitialized value is read and this did cause real world bugs when it doesn't matter what value is read). It also means the compiler is free to put whatever value they want there - one of the goals was the various sanitizers that check for using uninitialized values need to still work - the vast majority of the time when an uninitialized value is read that is a bug in the code. There are a lot of situations where a compiler cannot tell if a variable would be used uninitialized, so we can't rely on compiler warnings (it sometimes needs solving the halting problem).
- tialaramex 7mo ago
  > There are a lot of situations where a compiler cannot tell if a variable would be used uninitialized, so we can't rely on compiler warnings (it sometimes needs solving the halting problem). It's an explicit choice in C++ to always accept correct programs (the alternative being to always reject incorrect programs†). The committee does not have to stick by this bad decision in each C++ version, of course they aren't likely to stop making the same bad choice, but it is possible to do so. If you're allowed to take the other side, you can of course (Rust and several other languages do this) reject programs where the compiler isn't satisfied that you definitely always initialize the variable before it's value is needed. Most obviously (but it's pretty annoying, so Rust does not do this) you could insist on the initialization as part of the variable definition in the actual syntax. † You can't have both, by Rice's Theorem, Henry Rice got his PhD for figuring out how to prove this, last century, long before C++ was conceived. So you must pick, one or the other.
- aw1621107 7mo ago
  > there is 30 years of C++ in the real world, initializing everything by default unless you opt-in will break some performance critical code that should not initialize everything ...But the change to EB in this case does initialize everything by default?
  - bluGill 7mo ago
    No it doesn't. It says the value is unspecified but it exists. Sometimes some compilers did initialize everything (this was common in debug builds) before. Some of them will in the future, but most won't do anything difference. The only difference is some optimizer used to eliminate code paths where they could prove that path would read an uninitialized variable - causing a lot of weird bugs in the real world.
    - aw1621107 7mo ago
      > It says the value is unspecified but it exists. The precise value is not specified, but whatever value is picked also has to be something that isn't tied to the state of the program so some kind of initialization needs to take place. Furthermore, the proposal explicitly states that (some) variables are initialized by default: > Default-initialization of an automatic-storage object initializes the object with a fixed value defined by the implementation > The automatic storage for an automatic variable is always fully initialized, which has potential performance implications. > The automatic storage for an automatic variable is always fully initialized, which has potential performance implications.

tialaramex 7mo ago

> If you don't provide an initializer, the compiler inserts the default initializer for it. This requires that there is a default. Several modern languages (such as Go) insist on this, it means now your types don't even model reality in this very fundamental way. Who is a person's default spouse? Even where you can imagine a default it's sometimes undesirable to have one, for example we already live in a society where somebody decided default gender is male - and it might look too much like real data, default birthday being 1 January also matches hundreds of thousands of Americans... The most likely place you go after "Everything has a default" is the billion dollar mistake because you're inclined to just incorporate "or it's default invalid" into the type definition to get your default, and when you do that everywhere needs to have "check it's valid" code added, even if we already just checked that a moment ago.

kwsp 7mo ago
I don’t care that much about everything having a default (although it’s nice), but if a language insists on a default value for every type for safety, can’t you just use std::optional?
- tialaramex 7mo ago
  I can't tell if you imagine std::optional is a value (it is not) or if you know it's a templated type but you imagine that somehow it would be OK to redefine all programs so that every type is std::optional<T> of that type instead so as to simplify initialization. Either way no, that can't work.
  - MaxBarraclough 7mo ago
    > Either way no, that can't work. Kotlin has explicit nullable types. Rust has no null, but has option types. Both languages work fine. I think your point was that neither approach could reasonably be retrofitted to C++, do I have that right?
    - tialaramex 7mo ago