Upper/lower case rules, any chance they will be relaxed?

[c-smile]

As for now naming restrictions on types are limiting use of C3 quite a lot.

Especially in cases where C3 code needs to interact with external systems. E.g. HWND, MessageBox(), HELEMENT (in Sciter Engine), etc. are invalid type names from C3 standpoint.

Such limitations are probably OK in GoLang for example but in language that should use system API as it is ?

[p7r0x7]

fn void nameHere() @cname("nameThere")

?

[p7r0x7]

The lexer handles builtin types via their own unique tokens, ofc they don't interfere with the naming rules for identifiers. No, there are no implicit declarations as you describe.

[lerno]

What if to allow lexer to use alias and typedef declarations?

That is only possible in a language that has a single declaration order, not a multipass declaration order, as already mentioned.

This will work as lexer already has implicit declarations (AFAIU) like:

The lexer doesn't have such rules. int, float etc are built-in as keywords, this is the only way to get around the naming rules.

[c-smile]

The lexer handles builtin types via their own unique tokens

Sure. But that are implementation details that quite easily can be changed, pseudocode:

alias chars = char[];

enum TOKEN_TYPE {
    TOKEN_TYPE_TYPE,
    TOKEN_TYPE_CONST,
    TOKEN_TYPE_VAR,
};

TOKEN_TYPE classifyToken(chars tokenChars) {
    if( perfect_hash_builtin_types.find(tokenChars) ) return TOKEN_TYPE_TYPE;
    // to add this line:
    if( module->aliases.find(tokenChars) || module->typedefs.find(tokenChars))  return TOKEN_TYPE_TYPE; 
    ...
}

[lerno]

What you're suggesting is the lexer hack. The lexer hack does not work unless semantic analysis is done top down. Since C3 supports out of order declarations, i.e. Foo f; typedef Foo = int; the lexer hack does not work.

[lerno]

Furthermore we can have:

typedef Foo @if(some_macro()) = int;

In this case we do not know whether Foo actually exists until some_macro() is resolved.
On top of that, types may appear that are defined in other modules. Whether they should match or not is determined by visibility rules, that are not resolved until these types are resolved.

[c-smile]

That is only possible in a language that has a single declaration order, not a multipass declaration order, as already mentioned.

multipass is not needed.

I am pretty sure that scan_ident() can be refactored to classify type names without those ugly upper/lower case rules. Moreover some human languages are not using character cases at all ( ⅓ of Earth population, BTW). I believe that support of UNICODE in modern PLs is highly desirable.

I think that scan_indent() may take Lexer -> CompilationUnit -> (types and module_aliases) info for name classification.

At least such relaxed naming rules can be made local to compilation unit. This:

alias chars = char[];  // alias should be about types only, 
                                 // makes no sense in other contexts.
int classifyToken(chars tokenChars) { ... }

Does not require multipass and does not change language semantic, at all.

typename keyword is in C++ rougly for the same purpose/

[lerno]

You do know that C++ uses deferred parsing in order to solve out-of-order issues?

Again, the visibility of names is determined during semantic analysis. Names may or may not derive from other modules. In other words, we cannot feed back the name of the result of a parse of module A into the parse of module B, since the visibility of module A from B is not known at parse time.

The way D does this is the best possible solution while still allowing for arbitrary names: it outlaws some meaningless expression statements, such as foo * bar;. Then on top of this it then uses infinite lookahead (which in practice is no more than 1-2 tokens, but in theory may be unbounded).

Another solution is to create a scheme of deferred parsing, so that only modules, imports and typedefs and aliases are fully parsed and then things are parsed on demand. While theoretically possible, it's extremely hostile to tooling.

What definitely doesn't work is the scheme you propose.

As for unicode in identifiers, I am strongly opposed to them. See https://c3-lang.org/faq/rejected-ideas/#unicode-identifiers