the other day i forgot what but i had an idea about something to implement in the compiler that would be neat but not present in c
also need to be able to interface directly with assembly
also let the compiller trim unused symbole
adding a preprocessor to allow an include to not be completly used in the compiler
better for single header library, and also, add maybe a namespace or a directive to allow to multiple function to have the same name but give them different signature depending of their origin file exemple if their is a need to have two file that declare the same type, only specify what the user want, but it is to the user to know what they are doing, without needing to touch to the header file directly
anyway i see my point

Vision and Goals

Every type, from built-in to user-defined, must have a well-defined, consistent size. This includes basic pointers (void*) and even complex dynamically sized types.

The language should support both software rendering and GPU-accelerated graphics (e.g., via OpenGL or DirectX). This requires having a standardized interface or runtime layer that abstracts GPU calls while still allowing low-level access when needed.

Data layout in memory will be optimized for cache efficiency. This implies control over alignment, packing, and predictable memory layouts that might, for instance, allow SIMD operations or other low-level optimizations.

The language must be designed from the ground up to interface smoothly with C libraries. This means standardizing calling conventions and possibly even having a translation layer for linking external C code.

1. Language Design

low-level enough to manage memory and hardware directly (like C)
high-level enough to be safe and productive (optional but desirable)
well-specified, with a clear grammar and semantics
manual memory management
dtrong type system (static typing, ideally with type inference for ergonomics)
interfacing with system calls and external libraries
compilation model (AOT, also look at meta programming)
it should absolutly not look or feel like c++.
and it is not a plain copy of c also i will take some inspiration from holyc, it should not have oop at all

can target multiple architectures: x86_64, ARM, RISC-V, MIPS. (for starter x64 and ARM)
outputs native binaries, or optionally transpiles to C or LLVM IR
is self-hosted, eventually (bootstraps itself)
has cross-compilation built in
need to look into backend (LLVM or Cranelift) or build myself one

each OS has its own api:
- syscalls.
- file systems.
- I/O.
- threading.
first i will aim for linux (i will dev on sleepeelinux (my own minimal operating system UwU))
runtime library (like libc musl) that wraps OS specifics into a unified API
fallback implementations for exotic or minimal platforms (embedded)

no fork you all, it will be open source, but most people are bad at programming so no if you want to work on it fork it -_-

undefined behavior are a nono.
new version should not break old behavior, it need to be robust so that people that write in 20year can use code from today
binary compatibility with system libraries or foreign function interfaces (FFI).
platform-specific optimizations. if a feature aim for a platforme, optimize it for it.
designing something portable and performant today is hard but maintaining that over decades is harder so yeah good look <3

No ambiguity: Instantiation only allowed when rules are met
Strict typing: Prevents C++-style template bloat or implicit struct operations
C compatibility: Resulting functions look like plain C
Low-level: You control when, how, and what gets generated
my idea isn't to recreate the wheel but expand on thing that i like without falling into what c++ or other c inspired lang are
for now i am just writing idea, i'll need a lot more work to have a robust design, i am not better than other, i am more flawed, but i'll aim for self improvement