Hacker News Reader

Comment by naruhodo | Hacker News Reader

I'm don't understand why he needs '==' to specify namespace and type aliases, also mentioned here[1]. Why not just '='? Show your working, Herb!

Also starting enums at 1 instead of 0 is an odd choice, if you'll pardon the pun.

[1] https://herbsutter.com/2023/04/30/cppfront-spring-update/

View on HN

FTA: In the April blog post, I mentioned I needed a way to write type and namespace aliases, and that because all Cpp2 declarations are of the form thing : type = value, I decided to try using the same syntax but with == to denote “always equal to.”

So, I think we have

  // new type
  foo = std::vector<int>;
  // alias of existing type
  bar == std::vector<int>;

I guess that could evolve to (or maybe already has evolved to?)

  // variable with initial value
  foo: int = 42;
  // constant
  bar: int == 42;

Oh... so the new type, foo, is distinct (not assignment-compatible) from std::vector<int>?

Yes, but functionally identical. See for example

Haskell type vs new type: https://typeclasses.com/coerce

Python NewType: https://docs.python.org/3/library/typing.html#newtype

I've always respected choosing 0 as an invalid state. It makes it much harder to accidentally have a function succeed if the default representation is "you messed up"

Wouldn't that mean that you should just define ERROR as the first enumeration constant, with value 0, rather than break out of the enum type?

It's really common though to use enums as array indices, which start at 0.

In practice I always choose the first enumeration to be a specific error of "you failed to initialise this".

I don't know that I've ever directly used an enum as an index, but I guess if I did I'd have to bias it.

If you start enums at 1, then the first item in the enum isn't coercible to false, all items coerce to true.

Reply on news.ycombinator.com