4 ms·
> but libc needs to keep the same API The "needs to" is debatable. Compared to the C++ stdlib, the C stdlib is so small that adding a modernized and incompatib
by flohofwoe 4y ago
> but libc needs to keep the same API
The "needs to" is debatable. Compared to the C++ stdlib, the C stdlib is so small that adding a modernized and incompatible "v2" next to "v1" is realistic. The effort could start as a 3rd party implementation similar to MUSL.
The old headers with the old APIs would still exist for "legacy code" but would generate "deprecated" warnings.
Once that new "3rd party stdlib" has proven itself in the real world, the C commitee might consider it for inclusion in the standard.
- stephc_int13 4y agoWould you keep the naming style?
- flohofwoe 4y agoNo, at the very least I would add a (reserved) stdc_ prefix to all stdlib functions (and defines, and header filenames...), and keep options open for API versioning (e.g. stdc2_...). That way we could also get rid of all the random reserved identifiers we need to (theoretically) adhere to now.
- stephc_int13 4y agoThat's a good start, at least for function names, not sure if I would use the same logic for everything. In practice I find the prefix style better than namespaces, as a way to avoid information scattering. Snake case would probably win the race, but I am not sure that many old-timers would be ready to let go the old habit of abbreviated function names. After a while we don't see it for what it is, but I think that most of the naming is ugly, especially the string functions...