C is Brittle D is Plastic

[Kapendev]

On Sunday, 5 April 2026 at 02:34:08 UTC, Cid Lib wrote:
> On Friday, 3 April 2026 at 18:49:19 UTC, Walter Bright wrote:
>> On 4/3/2026 12:03 AM, Richard (Rikki) Andrew Cattermole wrote:
>>> You should be contacting Uecker who is leading the memory 
>>> safety workgroup. 
>>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3211.pdf
>>
>> Done.
>
> If I were on the ISO C Committee, I would not see my job as 
> 'fixing' C, by trying to give it a brain, but rather ensuring 
> the language remains the 'somewhat' mindless guardian of legacy 
> code that it is, while simultaneously ensuring it remains a 
> language that can continue to be used in cases where it would 
> not be considered professionally negligent to do so.
>
> The only proposal I would 100% vote for, would be a proposal 
> for categorizing the C language to the world more correctly - 
> i.e. renaming it to UnsafeC (for example).
>
> Every attempt to 'fix' C, eventually just results in a 
> different language entirely.
>
> "The great thing about C is that it doesn't try to be smarter 
> than you. If I see p = q, I know exactly what the CPU is doing. 
> If p is a fat pointer, now the compiler is doing multi-word 
> copies and hidden arithmetic behind my back. And that is not 
> C!" - (A Hypothetical Linus)

A slice/view/span is literally just a struct and `=` would do 
exactly what you think it would do. You can even avoid `slice[0]` 
with a theoretical "BetterC" by using something like 
`__sget(slice, index)` to keep things more C like. Would return 
null on error.