3 ms·

The C++ type system is completely inadequate for these tasks. I thought of a rather nice way to picture it, the C++ type system is like you have Roman Numerals

The C++ type system is completely inadequate for these tasks. I thought of a rather nice way to picture it, the C++ type system is like you have Roman Numerals, and so now the notation itself fights trying to understand important concepts about numbers (types). Languages with a better type system are like having Arabic Numerals, it's not a panacea, but the notation allows significant improvements in expressiveness and teachability. This analogy seems especially apt because Roman Numerals lacked zero as I understand it, and the C++ type system doesn't cope well with the idea of ZSTs nor with the Empty types which are analogous to zero in type arithmetic.

pjmlp 3y ago
Actually it is more like having both Roman and Arabic Numerals on the same source code, depending on the age of the project, and the C and C++ education background of the team.
- tialaramex 3y ago
  I don't see any way to express something like Option<Infallible> in C++ Regardless of "age of the project" or other considerations, this doesn't seem like a particularly tricky edge case of generic programming and yet C++ is stumped AFAICT
  - acka 3y ago
    According[0] to Perplexity.ai, you could use std::optional<std::monostate> to get a C++ approximation of your Rust type. I am neither an expert in modern C++ nor in Rust, but I have witnessed enough of C++'s evolution over time to know that if C++ language devs find a feature desirable enough they will do whatever it takes to frobnicate the language in order to claim support for that feature. [0] https://www.perplexity.ai/search/is-it-possible-Sd3TML68TfKveHzIkoGTNA https://www.perplexity.ai/search/is-it-possible-Sd3TML68TfKv...
    - pjmlp 3y ago
      While I watch with some desmay, one of favourite languages turning beyond PL/I levels of complexity, it isn't alone in this direction. One of the reasons I am not able to follow up on C++ as much as I did in the past, isn't directly related to its complexity, rather that my main worktools, the JVM, CLR and Web ecosystems, are reaching similar levels of complexity, specially with the 6 months release candence, and there is only so much one can keep up with.
    - tialaramex 3y ago
      std::optional<std::monostate> has two values, Option<Infallible> has one, so by my counting that's a 100% error. It is likely the best that can be done, but that's my point, C++ can't do this because the foundational type system isn't up to the task.
    - GrantMoyer 3y ago
      std::monostate is a "unit type"[1]; there's only one value with with type monostate (the value is std::monostate{}), so all monostate values are equivalent. Infalible is a "empty type"[2]; there are no values with type Infalible, so a value cannot be constructed, so Optional<Infalible> is always None, never Some(infallible). Importantly, the compiler knows this and can use it to reason about the correctness of code. C++ has no empty types. Void is close, but it's sometimes used where a unit type would be used, and anyway it's not a first class type. For example, you can't use std::optional<void>. Even if it were possible to make an empty type in C++, it wouldn't give you anything, because the compiler isn't equipped to reason about them. BTW, the rust equivalent to std::optional<std::monostate> is Optional<()>. The empty tuple is Rust's idomatic unit type. [1]: https://en.wikipedia.org/wiki/Unit_type https://en.wikipedia.org/wiki/Unit_type [2]: https://en.wikipedia.org/wiki/Empty_type https://en.wikipedia.org/wiki/Empty_type
  - pjmlp 3y ago
    That wasn't really the point of my remark, rather C with Classes C++98 style with plenty of C style coding for strings and arrays (Roman Numerals), Modern C++ best pratices with safety tooling (Arabic Numerals).
jandrewrogers 3y ago
Current version of C++ can handle empty and zero-size types quite well, though you are correct that older versions of C++ had limited support (and non-existent pre-C++11). I create and use them regularly when metaprogramming. The bigger issue is that all of this new capability can't be easily grafted onto the old standard library. If you were to write a re-designed standard library from a C++20 baseline, and some people do, it is a dramatically different experience. Modern C++ is an amazing library-building language but the 'std' library it comes with is legacy rubbish in many regards.

pjmlp 3y ago

Actually it is more like having both Roman and Arabic Numerals on the same source code, depending on the age of the project, and the C and C++ education background of the team.

tialaramex 3y ago
I don't see any way to express something like Option<Infallible> in C++ Regardless of "age of the project" or other considerations, this doesn't seem like a particularly tricky edge case of generic programming and yet C++ is stumped AFAICT
- acka 3y ago
  According[0] to Perplexity.ai, you could use std::optional<std::monostate> to get a C++ approximation of your Rust type. I am neither an expert in modern C++ nor in Rust, but I have witnessed enough of C++'s evolution over time to know that if C++ language devs find a feature desirable enough they will do whatever it takes to frobnicate the language in order to claim support for that feature. [0] https://www.perplexity.ai/search/is-it-possible-Sd3TML68TfKveHzIkoGTNA https://www.perplexity.ai/search/is-it-possible-Sd3TML68TfKv...
  - pjmlp 3y ago
    While I watch with some desmay, one of favourite languages turning beyond PL/I levels of complexity, it isn't alone in this direction. One of the reasons I am not able to follow up on C++ as much as I did in the past, isn't directly related to its complexity, rather that my main worktools, the JVM, CLR and Web ecosystems, are reaching similar levels of complexity, specially with the 6 months release candence, and there is only so much one can keep up with.
  - tialaramex 3y ago
    std::optional<std::monostate> has two values, Option<Infallible> has one, so by my counting that's a 100% error. It is likely the best that can be done, but that's my point, C++ can't do this because the foundational type system isn't up to the task.
  - GrantMoyer 3y ago
    std::monostate is a "unit type"[1]; there's only one value with with type monostate (the value is std::monostate{}), so all monostate values are equivalent. Infalible is a "empty type"[2]; there are no values with type Infalible, so a value cannot be constructed, so Optional<Infalible> is always None, never Some(infallible). Importantly, the compiler knows this and can use it to reason about the correctness of code. C++ has no empty types. Void is close, but it's sometimes used where a unit type would be used, and anyway it's not a first class type. For example, you can't use std::optional<void>. Even if it were possible to make an empty type in C++, it wouldn't give you anything, because the compiler isn't equipped to reason about them. BTW, the rust equivalent to std::optional<std::monostate> is Optional<()>. The empty tuple is Rust's idomatic unit type. [1]: https://en.wikipedia.org/wiki/Unit_type https://en.wikipedia.org/wiki/Unit_type [2]: https://en.wikipedia.org/wiki/Empty_type https://en.wikipedia.org/wiki/Empty_type
- pjmlp 3y ago
  That wasn't really the point of my remark, rather C with Classes C++98 style with plenty of C style coding for strings and arrays (Roman Numerals), Modern C++ best pratices with safety tooling (Arabic Numerals).

jandrewrogers 3y ago

Current version of C++ can handle empty and zero-size types quite well, though you are correct that older versions of C++ had limited support (and non-existent pre-C++11). I create and use them regularly when metaprogramming. The bigger issue is that all of this new capability can't be easily grafted onto the old standard library. If you were to write a re-designed standard library from a C++20 baseline, and some people do, it is a dramatically different experience. Modern C++ is an amazing library-building language but the 'std' library it comes with is legacy rubbish in many regards.