Comment by WalterBright
1 day ago
https://spader.zone/sp/#null-terminated-strings-are-the-devi...
Pointer/length is not just for strings - but for all arrays.
See my proposal:
1 day ago
https://spader.zone/sp/#null-terminated-strings-are-the-devi...
Pointer/length is not just for strings - but for all arrays.
See my proposal:
A comment from a legend. Thanks for reading and thanks for the response! I agree; the dynamic array is typed as a T* for ergonomics sake but is similarly a pointer and a length (and an allocator).
Could I pick your brain a little more on the design? I'm spader at spader.zone; if you have time, drop me an email. I promise not to take too much of your time and I'd love to hear from you.
Thanks for the kind words!
This can get you started:
https://dlang.org/spec/arrays.html
Strings (and arrays) being length/ptr is a freaking enormous win, in simplicity, performance, and overflow bug elimination.
One of D's secret features is that string literals still have a 0 appended to them, even though the length of the string does not include the 0. This makes it super slick to call C functions, like printf, using a string literal for the format string.
I'm baffled why C spends its energy doing things like normalized Unicode identifiers (an abomination) instead of something incredibly useful like length/ptr arrays.
I use a C dialect with (ptr,ptr) slices and (ptr,ptr,ptr,ptr) buffers. Effectively a different programming language, still uses standard C compiler.
https://github.com/gritzko/libabc
In this day and age, the top problem is Claude bringing lots and lots of bad C into the code base. Takes a weekend to clear the week's mess.
https://github.com/gritzko/beagle
In a cleared codebase though all the usual C memory bugs are virtually non-existant. When did I see core dump last time? I do not remember. Thus feel no urge to use Zig or Rust.
Congrats! I had many years of chasing memory bugs. It certainly influenced the design of D a lot.
Interestingly, I rarely make a memory bug these days. Too much experience, I've just learned not to make them.
But I still prefer to use language features that make it easier to not make such errors.
I suggest using a slightly different array operator syntax for fat pointer arrays: "char a[|..|]" instead of just "char a[..]" to make them visually distinct and indicate that element access has additional bounds check. (syntax inspired by ocaml)
Thank you for the idea! I have no experience with Ocaml, so have no opinion on it. My experience is the simpler the syntax, the more people will use it.
But won't all those posix functions that take only `const char*` parameters need to be changed to be pointer/length?
No. For string literals, they already have a 0 appended, so no problem. For others, you'll need to malloc/copy/free.
It hasn't been much of an issue with decades of D code.