deleted

[acbaile]

deleted

[bas]

I can easily image developers initially being irritated by something like this. It takes away some
of the freedom. However all C2 code then becomes a lot more similar and thus more readable. This is
a huge advantage. For the same reasion the Go language formats all libraries with the same required
style. Initially developers hate it, but in the end, code is So much more readable (and reusable).

[magnusi]

I would much prefer it being a warning rather than a hard error (for reasons of FFI), but I agree with Bas that clear style is extremely beneficial, especially if you look at how horrible C look, where people use all sorts of indentation styles, naming schemes (especially juicy is some peoples' tendency to append _t to their types, which is a suffix belonging to POSIX only) and casing, which can result in a plenty of inconsistencies.

[lerno]

Interestingly, if we enforce the type casing we can simplify analysis quite a bit:

• Types are the built in ones (as keywords) + anything starting with uppercase.
• Identifiers are anything starting with lowercase (i.e. variables, function names)
• Initial underscores are allowed and skipped when determining against these rules (so __Foo is a type, __foo is a
  an identifier)
• Reserve anything starting with a single _ for user use (so allowed), double __ is reserved for internal use, so is disallowed. Same rules inside of indentifiers/types: Foo_bar is allowed, Foo__bar is not allowed.
• Reserve __x_, __X_ prefix to bypass name rules externally. So __x_Foo would match an external symbol "Foo" assumed to be a function/variable. __X_foo would match an external symbol "foo" assumed to be a type. An exported function __x_Foo would be exported externally as Foo to C/C++.

[bas]

Interestingly, we don't use the casing during parsing/analysis, we only check if it's correct.
Since C2 hasn't (yet) solved the issue of (C-code)

Code: [Select]

const int* const
The analyser doesn't see pointer variables as constant. When should a variable be a constant:
if it points to a constant or if it is a constant pointer to a (dynamic) variable?

[lerno]

So what about it, should we use it during parsing? That way we can skip some steps during analysis.