21 comments

[ 0.23 ms ] story [ 11.4 ms ] thread
reads more like a Wishlist rather than actual implementable specs.
every spec is implementable

some just delegate more or less to the implementation

Before I read this, what is there about C3 [0] you don't like?

[0] https://c3-lang.org

C3 is an embarrassing mess regarding integer types and sizes, missing C99's stdint.h defs, for example.
To clarify: C3 has fixed sized ints. I think the parent poster doesn’t like their name, but they are fixed sized, as follows:

  Name    Size    Signed
  bool†   1       no
  ichar   8       yes
  char    8       no
  short   16      yes
  ushort  16      no
  int     32      yes
  uint    32      no
  long    64      yes
  ulong   64      no
  int128  128     yes
  uint128 128     no
Source: https://c3-lang.org/language-overview/types/#integer-types
i reckon it's easy enough to alias the stdint.h types and define them in terms of the size definitions above. i'd forgotten that the C3 pointer types are the ones whose bit size varies by platform. mea culpa.
This is certainly copying off Rust's homework...
Who copied off Haskells homework, so here we are.
And cloudflare still somehow shipped a rust binary that crashed half the internet.
and I've had Haskell binaries attempt to use infinite quantities of RAM (looking at an old version of dconf2nix here) and thus crash
This doesnt seems to be meaningfully different from Rust.

> does not require tracing garbage collection

Just call it garbage collection.

(Applies in two ways: if you think that garbage collection subsumes reference counting then this language doesn’t require garbage collection in the sense that it also doesn’t require reference counting; if you think that garbage collection does not subsume reference counting then there’s no point in saying three words when you can say two.)

It's less specified than rust. For example, you can bind references to individual collection elements here. It doesn't seem to prohibit borrowing a dynamically indexed element either, which is one hell of a static analysis lift. Seems like you can also have simultaneous references to distinct static indices (e.g. &mut arr[0] and &mut arr[1]) as long as you don't do invalidating operations, which isn't expressible in NLL or polonius. That's feasible for a borrowchecker at least.
This is so obviously written by ChatGPT from what I can tell. Not even an attempt to copyedit it unless I missed something.
This comment was obviously written by Opus 3.8. Not even 4.0.
...and UI is clearly spotable as AI generated with whatever tool....
It's great to have it all spec'd out. However, I think specs like this suffer the same fate as war plans: they get modified quickly as soon as implementation begins. Nonetheless, it's good to have a clear idea of where you're headed. I just wouldn't call it "Final."
Another one?
Yes, but remember is the last appendix to a book, and book provides the context for this appendix. So yes, in that sense, it's just another one attempting to address the memory-safety issues of C. At least this one uses C like syntax and doesn't require C programmers to learn some alien syntax. Of course, this is just a spec, Rust is well and truly live in the environment. The book is more interesting than the spec.
Odin's turn to be "the sucessor of C" is due this month
According to ChatGPT, the CobaltC language specification does now (since the spec was recently updated with an errata) provide sufficient syntactic, structural, and semantic boundaries to begin high-level compiler implementation planning, despite intentionally leaving lower-level mechanical decisions to the developer.