The point in my comment is that every single item in C++ was wanted and championed by someone, exactly like all the talk about adding this and that to C.
> C shouldn't turn into C++
Well, C did turn into C++. The entity that gave forth C++ is C.
Analogy: when we say "apes turned into humans", we don't mean that apes don't exist any more or are not continuing to evolve.
Since C++ is here, there is no need for C to turn into another C++ again.
A good way to have a C++ with fewer features would be to trim from C++ rather than add to C.
If you want your arrays type-safe you'll need dark macro magic (actually possible in the latest standards I think) or proper templates/generics.
If you really want to make your arrays convenient to use you'll want destructors and RAII.
Then you'd like to be able to conveniently search, sort and filter those arrays. That's clunky without lambdas.
And once you get all that, why not move semantics and...
Conversely if you don't want any of this what's wrong with:
struct my_array {
my_type_t *buf;
size_t len;
}
I don't think that's true at all.
1. "arr[3]" syntax can just be part of the language.
2. For length, we already have the "sizeof()" syntax, although admittedly it is a compile-time construct and expanding it to runtime could be confusing. I am ok with using a standard psuedo-function for array-len and would absolutely prefer it to syntax treating first-class arrays as virtual structs with virtual 'len' members.
3. I don't think any C practitioner wants "arr1 += arr2" style magic.
So I don't buy that there is a need for operator overload; the rest of your claims that this is basically an ask for C++ follow baselessly from that premise.
As I suggested, adding a(n optional) constraint such that "buf" can be limited by "len" in such a struct is a possible approach to offering safer arrays. Such a change seems like it kinda requires a change to the language.
I know, this is pedantic, I suppose. Mea culpa.
This is irrelevant to the point I made in the text you quoted.
> Well, C did turn into C++. The entity that gave forth C++ is C.
My mother didn't turn into me. She just gave rise to me. She's still alive and well.
My point, which seems to have completely escaped you, is that C itself should not turn into C++, so claims that any attempt at all ever to improve C with the addition of a single constraint mechanism for managing pointer size safely is a slipper slope to duplicating what C++ has become, leaving no non-C++ C language in its wake -- well, such claims seem unlikely to be an unavoidable Truth.
> A good way to have a C++ with fewer features would be to trim from C++ rather than add to C.
Again, my point is not easily crammed into the round hole of your idea of how things worked. It is, instead, that C can have a few more safety features without becoming "C++ with fewer features".
I feel like you didn't read my previous message as a whole at all given the way you responded to it, and just looked for trigger words you could use to push some kind of preconceived notions.
C shouldn't turn into C++, or even C++ Lite™, but it shouldn't remain strictly unchanging for all eternity, either. It should just always strive to be a better C, conservatively, because its niche is one where conservative advancement is important.
Some way to adopt programming practices that guaranteee consistent management of array and pointer length -- not just write code to check it, but actually guarantee it -- would, I think, perfectly fit the needs of conservative advancement suitable to C's most important niche(s). It may not take the form of a Rust-like "fat pointer". It may just be the ability to tell the compiler to enforce a particular constraint for relationships between specific struct fields/members (as someone else in this discussion suggested), in a backward-compatible manner such that the exact same code would compile in an older-standard compiler -- a very conservative approach that should, in fact, solve the problem as well as "fat pointers".
There are ways to get the actually important upgrades without recreating C++.