[HendrikHensen]

If this is to be a real, (relatively) widely-used language, I would make some tough choices on where to innovate, and where to just leave things the same.

One thing I noticed in the example is `num target`, especially because the focus is on "clarity". When I read the example, I was sure that `num` would be something like the JavaScript `Number` type. But to my surprise, it's just a 64-bit integer.

For an extremely long time, languages have had "int", "integer", "int64", and similar. If you aim for clarity, I would strongly advise to just keep those names and don't try to invent new words for them just because. Both because of familiarity (most programmers coming to your language will already be familiar other languages which have "int(eger)"), and because of clarity ("int(eger)" is unambiguous, it is a well defined term to mean a round number; "num" is ambiguous and "number" can mean any type of number, e.g. integer, decimal, imaginary, complex, etc).

The most clear are when the data types are fully explicit, eg. `int64` (signed), `uint64` (unsigned), `int32`, etc.

[hedayet]

[author here] That’s a good point. I can see why int might be clearer than num, especially given the long history of that naming. I’ll think about it.

[Nevermark]

Definitely int for signed numbers. But I would call it "int64".

Clarity means saying what you mean. The typename int64 could not be clearer that you are getting 64 bits.

This is consistent with your (num32 -->) "int32".

And it would remain consistent if you later add smaller or larger integers.

This also fits your philosophy of letting the developer decide and getting out of their way. I.e. don't use naming to somehow shoehorn in the "standard" int size. Even if you would often be right. Make/let the developer make a conscious decision.

Later, "int" could be a big integer, with no bit limit. Or the name will be available for someone else to create that.

I do like your approach.

(For unsigned, I would call them "nat32", "nat64", if you ever go there. I.e. unsigned int is actually an oxymoron. A sign is what defines an integer. Natural numbers are the unsigned ones. This would be a case of using the standard math term for its standard meaning, instead of the odd historical accident found in C. Math is more universal, has more lasting and careful terminology - befitting universal clarity. I am not a fan of new names for things for specialized contexts. It just adds confusion or distance between branches of knowledge for no reason. Just a thought.)

[jiggawatts]

I would recommend outright copying Rust.

Among other things, it's a systems programming language and hence its naming scheme is largely (if not entirely) compatible with modern C++ types.

I.e.:

    +----------------+-------------------------+------------------------------+
    | Rust           | Modern C++              | Notes                        |
    +----------------+-------------------------+------------------------------+
    | i8             | std::int8_t             | exact 8-bit signed           |
    | u8             | std::uint8_t            | exact 8-bit unsigned         |
    | i16            | std::int16_t            | exact 16-bit signed          |
    | u16            | std::uint16_t           | exact 16-bit unsigned        |
    | i32            | std::int32_t            | exact 32-bit signed          |
    | u32            | std::uint32_t           | exact 32-bit unsigned        |
    | i64            | std::int64_t            | exact 64-bit signed          |
    | u64            | std::uint64_t           | exact 64-bit unsigned        |
    | i128           | (no standard type)      | GCC/Clang: __int128          |
    | u128           | (no standard type)      | GCC/Clang: unsigned __int128 |
    | isize          | std::intptr_t           | pointer-sized signed         |
    | usize          | std::uintptr_t          | pointer-sized unsigned       |
    | f32            | float                   | IEEE-754 single precision    |
    | f64            | double                  | IEEE-754 double precision    |
    | bool           | bool                    | same semantics               |
    | char           | char32_t                | Unicode scalar value         |
    +----------------+-------------------------+------------------------------+