Basic list of improvement points

[bas]

There have been some really good ideas and improvement points on this forum. The problem is that there are so many.
I would hate to miss or lose some ideas simply because there is no way to implement them all at once. So I'm looking at
some way to organize this.

More matured languages (Python for example) seem to have formalized this process by using PIPs (Python Improvement Proposals).
That is very nice for gradual improvements, but not handy when the base is not complete yet. Maybe we can have a list of items here,
that point to various other posts on the forum, along with their status. I'll update the list (and maybe prioritize a bit).

[bas]

The list so far: (unordered)

• restrict keyword - seems good, need to investigate consequences (http://www.c2lang.org/forum/index.php?topic=91.0)
• generics - require a lot of discussion still
• operator precedence - will be updated (http://www.c2lang.org/forum/index.php?topic=100.0)
• macro system - under discussion. Especially outer-loop macros seem promising
• isize/usize - need to be implemented
• cast syntax - the current cast syntax is ugly and doesn't fit in the rest, need better one

[lerno]

The easiest way would be to start by filing them as issues on the c2compiler in github.

[lerno]

A problem with working on the syntax though: any keyword must first be updated in the clang fork It makes dev harder since you have to know the workings of [part of] clang as well as C2's source. Some of C2Parser seems to be doing C/C++ parsing (commented out at steps). Cleaning out those remnants would make it easier for further refactorings.

I've made a stab at moving DiagnosticsEngine to be wrapped by "our own" class in a step to refactor things. I had to cheat at some places and obviously the diag:: messages had to be left as is, but maybe if there's some specification as to how C2 uses the Preprocessor, Lexer, DiagnosticsEngine and SourceManager so it's easier to know what can be stripped out in what order.

Obviously since since you wrote the whole thing in the first place you probably would have an easier time than me ripping out the Clang code, but for me (and any other contributor) it has to be done piecemeal so nothing gets broken by accident.

Maybe write up some specs? That would be useful for later anyway.

[lerno]

Some more points (to be evaluated)

- Zero cost errors - discussion needed
- Nested comments - proposal exists (probably wait for a new lexer to do this)
- Extended switch/case - proposal exists
- C11 _Generic (type-switched macros)
- Real arrays (fat pointers) - discussion needed
- Expression blocks (like gcc's ({ }) expression statements) - proposal exists
- Defer - proposal exists
- Allocator push/pop functionality - discussion needed
- Ergonomics: native string, growable array, map - discussion needed
- Return native register size (32 / 64?) - discussion needed
- Custom C2 Lexer