i64 vs int64

[emlai]

Using C++-like integer type names such as int64 over Rust-like i64 has been suggested multiple of times: #1690, #1496, #1520 (reply in thread), #1686.

• A commonly raised point is familiarity, and since we're creating a successor language, familiarity should be one of the top priorities when it doesn't conflict with other goals. Since the primary target audience, C++ users, already use int64_t, there is considerable precedent for the int64-style naming.
• the "principle of least surprise" goal: renaming basic and well-accepted integer types without a major reason can be considered surprising. It creates yet another thing adopters will need to learn.
• Language strangeness budget: we can only change so many things before the language completely alienates itself from its target audience. Is the change from int64 to i64 important enough to warrant spending that budget?
• Some people consider i64 too short for readability. I've never heard anyone complain about int64 being too long.
• Another successful successor language, Swift, uses Int64-style naming. Out of the major languages, only Rust (which is not a successor language) uses the i64-style naming.

Creating a poll to see what the Carbon community thinks.

[soc]

Neither? Not sure what's the point of digging out mixed-case types again?

Either types should start with uppercase letters, or they should start with lowercase letters. Having special rules for 7(?) types that get to start with a lowercase letter, while all the other types start with uppercase letters feels pretty silly in 2022.

To be honest ...

The signed-integer type with bit width N may be written Carbon.Int(N). For convenience and brevity, the common power-of-two sizes may be written with an i followed by the size: i8, i16, i32, i64, i128, or i256.

... seems to be the worst of both worlds.

[yssource]

i64 good for me.

Do you like float64?

f64 vs float64?

[0xBLCKLPTN]

I think float64 is much better than f64 because it is more readable, which is one of the advantages of this language. Yes, f64 is shorter, but for newbies it's easier to use float64 to study someone else's code in the future ;)

[WarEagle451]

I think float64 is much better than f64 because it is more readable, which is one of the advantages of this language. Yes, f64 is shorter, but for newbies it's easier to use float64 to study someone else's code in the future ;)

The language is not meant for new comers. While it would be good to consider new comers cleanliness takes priority IMO

[0xBLCKLPTN]

I think float64 is much better than f64 because it is more readable, which is one of the advantages of this language. Yes, f64 is shorter, but for newbies it's easier to use float64 to study someone else's code in the future ;)

The language is not meant for new comers. While it would be good to consider new comers cleanliness takes priority IMO

Сlean code equals intelligibility IMHO

[WarEagle451]

Clean code equals intelligibility IMHO

How is f64 less intelligible than float64? I don't think it is, nor have I ever seen someone be confused by it before. Plus it's less characters and therefore cleaner

[0xBLCKLPTN]

How is f64 less intelligible than float64? I don't think it is, nor have I ever seen someone be confused by it before. Plus it's less characters and therefore cleaner

In fact, I wrote a great example that abbreviations don't always make code easier, however, if you're in a hurry to write code, I don't mind having f64 instead of float64.

[MichaelBonnet]

I think principle of least surprise is the best approach here. It also serves the "gentle learning curve with reasonable familiarity for C++ developers" goal.

[jonmeow]

@YagaoDirac Please don't use sarcasm. We want our forums to remain kind and courteous. You can express disagreement without it. Please review our code of conduct: https://github.com/carbon-language/carbon-lang/blob/trunk/CODE_OF_CONDUCT.md

[Jakobovski]

Experienced c++ programmers CANNOT guess what i64 is???? This is not surprising, it's too classic to be any more classic. So why not integer64bits. It's so clear and never surprises any one.

Yes experienced C++ programmers can guess. But just because someone can guess does not mean its a good idea. When designing a language, or code in general, its best to design it in such a way that cognitive load is reduced as much as possible. Users only have so much cognitive capacity and it should be conserved for more important uses than trying to remember what i64 is when a simple int64 will do

We must also consider non-experienced engineers, who will not be as quick to guess the meaning if i64 or f64.

The less ambiguity in a language/code, the better. Of course is must be balanced with readability thats why we don't choose integer64 because its just a bit too verbose and the benefits of the extra characters are not that great. i is pretty ambiguous int is not much more ambiguous than integer

[WarEagle451]

We must also consider non-experienced engineers, who will not be as quick to guess the meaning if i64 or f64.

I understand your point, but I have some counter points.

• You're correct that i is ambiguous, but that's like saying what does L mean without telling you what acronym I'm using, the trailing 8, 16, etc, that's part that makes i64 not ambiguous
• Quick Google search
• Brevity
• Carbon is not supposed to be a easy entry point to people learning to program. (I'm not saying make it hard either)
• C++ and C is infinity worse with short, int, long, long long, float, double, there never seems to be much confusion to what they mean to anyone past a month of coding experience (Usually I see confusion with signed vs unsigned).
• i8, u8, etc, would is very useful for a pre / post fix when naming functions or methods and look better if it matches the keyword.
• People will understand it easily, as most understand acronyms like "IMO", "LMK" and "BRB" because they use them, anyone who uses Carbon past a couple of days will use the keywords regardless of their names.

My personal experience with C++ is that I when from using unsigned long long to uint64_t within days, than uint64_t to uint64 because the underscores were annoy, than uint64 to u64 because 3 characters is a lot easier to write than 6. I'd rather included a file with the using x = y everywhere than write uint64_t.

Final point. I have yet to see anyone in this community be confused about it, and there is a lot of novices here. So I see this as a non issue that will create work to do, yet (According to the poll) ~50% of people might just go out of their way to try and rename them back to what they currently are, which I would absolutely do in my code base.

[WarEagle451]

As I'm against changing the keyword names I'll list my counter points

• Anyone who uses Carbon will know what they mean because they use the keywords
• Brevity
• C++ and C are infinitely worse, yet only beginners are confused for a few days if not hours
• I also haven't seen many people complain about this
• This would create more work for what I view as a non issue
• i and u are not ambiguous because of the trailing numbers
• Common acronyms and shortening of trivial things are very common and accepted.
• Identical pre / postfixes not ambiguous because context matters. Eg, g for Green and g for global, (C++ code) static int g_my_global vs my_color_g.
• Pre / postfixes will look a lot better. RootU16() vs RootUInt16(). (I would even argue that the second is less readable)
• Carbon is meant to be a system language, which are naturally more difficult to understand if you are a beginner because many concepts like pointers are way more confusing than i64 vs int64

[YagaoDirac]

OK, sorry for that. I'll keep series and talk only the tech here. But don't be affected if you are pretty confident about some grammar level decision. Grammar is always trivial and doesn't really help. Carbon is not for better grammar, it's for a better high level ast orientation.

[dialupmars]

using i8 over int8 could confuse some people as to if "integer" is meant or "item", for example for (int i=0; i<n; ++i), both i and int are used, but do not mean the same thing.

[WarEagle451]

But if someone is using the language they wouldn't be able to name a variable i8? As I use C++ a lot I've never heard someone refer to the i in a index for loop as item, everyone I know just says it's commonly accepted and that it stands for int or index.

Another thing, there's plenty of C and C++ projects that rename the keywords to i16, f64, etc, if people are commonly willing to have an include file everywhere for that shortening of the keywords there must be a good reason

[bayrameker]

It makes more sense to start as int64 because people may have a hard time remembering the old syntax association with i64

[WarEagle451]

Could you give a situation? I get the impression that i64 is universally known to mean a 64 bit integer, maybe a new comer will have to google the keywords but that's normal for any language.

[YagaoDirac]

1, syntax is trivial. People should train to be able to read and write different syntax. This should not cost much time.
2, int is not good anymore. On some platform, int is 16bits and some are 64bits. int32 and i32 are both good enough.
3, I prefer i32 because I couldn't imagine how i32 would confuse experienced programmers. Programming is not a easy task. It takes time but a i32 doesn't take any time to remember or guess, or even search. Also Carbon is not meant to be a first language as a lot of people already mentioned.
4, Carbon probably has type alias syntax which solves this if this would be an issue.

[SamuelTrew]

To second this point, talking about what's going to be least surprising is pretty odd I find.
It's not as if some 20 year experienced cpp dev is going to go into shock that in64 isn't used in a successor languageil?

If you're not capable of using ever so slight (and more modern) syntax then that seems a bit odd.

[L4stR1t3s]

Wild suggestion:

int is a primitive template-style type that takes size as a template parameter (I will use c++ pseudo code using made up names):

int<8> i8 = 0;
int<32> i32 = 0;

Only allow parameter values for whatever the system it is being compiled for (currently typically 8, 16, 32, 64 and maybe 128). It makes no sense to allow int<7> if that means int<8> has to be allocated. So what if int<128> is not available on a system?

• You can not support that system.
• Or you can write specific code to handle specific cases:

if constexpr (is_available<int<128>>)
{
    int<128> i = ...;
}
else
{
    static_assert(is_available<int<64>>);
    int<64> i = ...;
}

• Or you could just use the largest or smallest available integer type that have their own type that is dynamically chosen by the compiler:

int_l i; // largest
int_s i; //smallest

But why stop there?

int<32, signed> // default
int<64, unsigned>

Let's go even further?

int<32, unsigned, overflow> // default (why? closest to what c++ has, porting existing code C++ code is easier if default behaviour matches)
int<64, signed, no_overflow>

Using i instead of int is obviously not a good idea in this case.

This would have to be fleshed out a lot more ofcourse, but I would be impressed if Carbon offers a mechanism to better deal with future evolutions in computing. How long have developers been porting 32-bit to 64-bit now?

[WarEagle451]

This would be similar to C++'s bitset. But I think this would be a very perplexing design choice

[urielgarciarivas]

What about supporting both?

[WarEagle451]

We definitely could, but I see some downsides.

• Opens the door to everyone uses different keywords that do the same thing
• Possible confusion
• In C++ long long turned into int64_t, i64, int64, and I'm sure more I can't think of

It would be best to avoid this and to stop users from declaring their own integer types (names)

[emlai]

That would go against the one way principle.

[L4stR1t3s]

It would be best to avoid this and to stop users from declaring their own integer types (names)

That would add serious unacceptable limitations:

struct Int32Object
{
    using int_type = int32_t;
};
struct Int64Object
{
    using int_type = int64_t;
};
template <class T>
struct IntObjectWrapper
{
    using int_type = typename T::int_type;
    static auto size()
    {
        return sizeof(int_type);
    }
};

[WarEagle451]

That would add serious unacceptable limitations:

I was referring to how in C++ we have using uint64_t = unsigned long long; It's not meant for metaprogramming. Code like that gets compiled away but it shouldn't exist in the first place but does because no sane (experienced) person is going to write unsigned long long 100s of times

[Jakobovski]

This is a bad idea IMO. Will make the code too confusing. People will think there is a difference between the two keywords.

[abiriadev]

as I know, type notations like i32 are not only used in Rust but also adapted by many languages like zig and verona and I think this is going to be a new 'standard way' to represent primitive types.

[Wajinn]

as I know, type notations like i32 are not only used in Rust but also adapted by many languages...

Other languages like Vlang, Odin, and Futhark also have such type notation.

It appears to be a very strong trend or direction in newer languages.