Hacker News Reader

Comment by jeffbee | Hacker News Reader

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`.

View on HN

The 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.

I 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.

I 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.

That'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.

I think you are thinking of the concept of "explicitness" not "expressiveness".

"On the expressive power of programming languages"

Matthias Felleisen

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.

The 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)`

The 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.

You’re repeating the type and hoping it doesn’t change when you really just wanted the value.

The 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.

And 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.

Reply on news.ycombinator.com