4 ms·
Odd that it says auto value = std::to_underlying(p); // C++23 is "more expressive" than uint8_t value = static_cast<uint8_t>(Permissions::Read); The lat
by jeffbee 2y ago
Odd that it says
auto value = std::to_underlying(p); // C++23
is "more expressive" than
uint8_t value = static_cast<uint8_t>(Permissions::Read);
The latter seems clearly more expressive, not less. You could tighten it up a bit by using auto on the LHS instead of the redundant uint8_t. In the former I don't know what's going on and I have to go read another header to figure out the type of `value`.
- CarpaDorada 2y agoThe expressibility of a language is what can be expressed in it, not what it can express to you. This additional feature allows you to express this projection without being explicit.
- jeffbee 2y agoI disagree. Any language can tell the computer what to do. The quality of a good language is that it also clearly communicates to human readers.
- rileymat2 2y agoI think expressiblity is trickier than that. You can think in a language with an imperative mindset where you are describing what to do, or another with a declarative mindset.
- justinpombrio 2y agoThat's true, but unrelated to the common usage of the word "expressiveness" when talking about programming languages. There's often a tradeoff between expressiveness and the thing you're talking about, which I'll call clarity. For example, macros increase expressiveness but decrease clarity. In Racket (or other lisps), you can define a macro `(my-let x 17 (+ x 1)) -> 18`. This is expressive, as most other languages don't let you define binding constructs so easily, but also bad for clarity because `my-let` doesn't look different than a regular function, so it's hard to tell at a glance that it's doing something a function could never do.
- dcsommer 2y agoI think you are thinking of the concept of "explicitness" not "expressiveness".
- soegaard 2y ago"On the expressive power of programming languages" Matthias Felleisen https://jgbm.github.io/eecs762f19/papers/felleisen.pdf https://jgbm.github.io/eecs762f19/papers/felleisen.pdf Abstract The literature on programming languages contains an abundance of informal claims on the relative expressive power of programming languages, but there is no framework for formalizing such statements nor for deriving interesting consequences. As a first step in this direction, we develop a formal notion of expressiveness and investigate its properties. To validate the theory, we analyze some widely held beliefs about the expressive power of several extensions of functional languages. Based on these results, we believe that our system correctly captures many of the informal ideas on expressiveness, and that it constitutes a foundation for further research in this direction.
- frozenport 2y agoYou’re repeating the type and hoping it doesn’t change when you really just wanted the value.
- kevin_thibedeau 2y agoAnd when the enum values don't fit into the uint8_t? If you want the enum variables constrained to an integer type do that in the enum definition itself. The compiler can then bark at you when you add a member outside the range.
- Conscat 2y agoThe former is more expressive because it doesn't require a template to manually deduce the underlying type of an enum as `static_cast<std::underlying_type_t<Permissions>>(Permissions::Read)`
- quietbritishjim 2y agoThe first is expressive in that you know that the "value" variable definitely ends up with the underlying numerical type of the Permissions enum, whereas in the second perhaps that static_cast is changing from a different numeric type.
- Maxatar 2y agoThe first is more expressive, the second is more explicit. The expressiveness of an expression allows it to be used in more contexts, such as in generic code where the underlying type may not be known.