Skip to content

Rejected Ideas

These are ideas that will not be implemented in C3.

The rationale for each is also given below.

Constructors and destructors

A fundamental concept in C3 is that data is not "active". This is to say there is no code associated with the data implicitly, unlike constructors and destructors in an object oriented language. Not having constructors / destructors prevents RAII-style resource handling, but also allows the code to assume the memory can be freely allocated and initialized as it sees fit, without causing any corruption or undefined behaviour.

There is a fundamental difference between active objects and inert data. Each has its advantages and disadvantages. C3 follows the C model, which is that data is passive and does not enforce any behaviour. This has very deep implications on the semantics of the language and adding constructors and destructors would change the language greatly, requiring many parts of the language to be altered.

For that reason, constructors and destructors will not be considered for C3.

Unicode identifiers

The main argument for unicode identifiers is that "it allows people to code in their own language". However, there is no proof that this actually is used in practice. Furthermore there are practical issues, such as bidirectional text, characters with different code points that are rendered in an identical way, etc.

Given the complexity and the lack of actual proven benefit, unicode identifiers will not happen for C3.

Builtin type-name variants

A common request is to change the builtin type names from char, int, long etc, to some other standard, such as u8 i32 or uint8, int32. Various rationales are usually given for each, but ultimately it is a matter of taste and habit.

Because C3 limits user-defined names to PascalCase in order to easily resolve the language grammar, it is not possible to create type aliases for such names, which leads to requests to build them into the language itself. (Int32 is fine, but int32 is not, nor are INT32 and I32).

Originally, C3 was going to have both bit-fixed type names (like today, where int is always 32 bits, long always 64 bits and so on) as well as explicit bitsize-names like u8, i32 that aliased to the same types. Ultimately this was shelved, because it would mean that libraries would end up standardizing on one style or the other, creating friction when used. Ultimately the language would end up with one style being the "accepted" way to name things anyway. So after quite a bit of deliberation, the C naming scheme was chosen. This was mainly for the following three reasons:

  1. It's familiar from C, so one would need to rewrite and learn less coming from C/C++/C#/Java, the code would also look more C-like.
  2. i32 has readability problems when combined with i for index in for loops, which was considered a major drawback.
  3. While the int32 scheme does not have readability issues, it is longer than the C names in almost every case.

After this decision was made and the types established, someone mentioned that s32 could have been an alternative to consider as well, and indeed it is far superior as a prefix for bitsize-names. However, it's not obvious that for example sptr is better than iptr, plus the decision was made.

Over the years, requests for builtin types have occasionally appeared, but interestingly, not always arguing for the same scheme. Some would say iXX was the only possibility, others thought such naming was out of the question and an intXX scheme the only right decision and so on. Given that, it's rather clear that the preference for any naming scheme is subjective, and one is pretty much as good as the other.

So, the C3 naming scheme will not change, although small tweaks are not ruled out.

String interpolation

There is sometimes the request for string interpolation in the style of:

String str1 = "hello";
String str2 = "world";
int val = 3;
float pi = 3.14;
String str = "{str1}:{str2}:{val}:{pi}";
  1. This is not a replacement for printf, as it assumes that the format string is always known at compile time. This is not always the case.
  2. This is often surprisingly hard to read compared to printf, except in simple cases or when dealing with huge string templates. In the latter case it doesn't need to be a language builtin.
  3. The general runtime case needs implicit allocation, which isn't compatible with C3 memory management.
  4. Compile time string generation already has @sprintf.
  5. The main downside of printf is when accidentally providing too many or too few arguments, but the C3 compiler already checks for that.
  6. This solution is as complex as printf and they strongly overlap – printf won't get removed, so adding it would mean there are two ways of achieving the same thing (except printf doesn't have any of its downsides)

For these reasons, C3 won't get string interpolation syntax.