Re: [RFC SPEC] Primitive data types and arrays

["Carlos Maniero" <carlos@maniero.me>]

About arrays, Johnny has suggested to talk about arrays in a different
thread, I'm just waiting us to conclude this discussion and I'll start
another thread to define Olang's array specification. But we brought
excellent points, and maybe we should define pointers before arrays.

> Obviously, `boolean` can be either `true` or `false`, but what should
> that mean? If `boolean` is mapped to `u8`, then zero and non-zero?

IMO, true should be 1 and false 0 in a way that *1 == true* is true and
*2 == true* is false. Control flow structures may accept anything not
just booleans and may apply the non-zero approach you described, but we
can discuss this on their own RFC (that does not exists yet).

> But the real question is what would `char` be? If the language should
> support Unicode properly, then `char` would represent a _code unit_
> rather than a "character", which could be considered a misnomer. Since
> Unicode uses variable-length characters, a Unicode character might be
> difficult to represent as just `char`.
>
> If no Unicode support is planned, then `char` as `u8` is good enough to
> represent characters in 7-bit ASCII encoding.

I'll be honest with you, It makes a lot of sense all you said, making a
char a u8 seems to enforce an Western-Eurocentrism in Olang. But I
confess that I never stopped to learn more about unicode.

At the same time I think we should support a 32-bit sized unicode char,
I don't wanna make all chars an u32 keeping the support to ASCII encoding.

IMO, we should either postpone specifying a char right now or assume
that a char at this point represents an ASCII char and start a new RFC
about unicode where we may define something like an unicode char.

BTW, you seem well versed on the unicode theory, would you like to
purpose a mechanism to deal with unicode?

> Note that in most languages where there is a `void` type, the `void`
> type is not actually valid in variable declarations. [...]
>
> In the current version of the spec, it would be included in
> <return-type>, rather than <type>, to allow it only as a function
> return type.

Agree!

> Also, there are three other types that might be interesting, if I may
> suggest: `never` (from TypeScript [1]), `unit` (from functional-like
> languages [2]) and `null` (from ECMAScript specs [3]).
>
> [1]: https://www.typescriptlang.org/docs/handbook/2/functions.html#never
> [2]: https://en.wikipedia.org/wiki/Unit_type
> [3]: https://tc39.es/ecma262/multipage/overview.html#sec-null-value

They seems to be very specific, we may wanna to wait until we find an
use for them.