D mentioned on Rust discussions site

[Dibyendu Majumdar]

On Saturday, 23 May 2020 at 23:50:55 UTC, Andrei Alexandrescu 
wrote:
> On 5/23/20 4:11 PM, Dibyendu Majumdar wrote:
>> On Saturday, 23 May 2020 at 17:08:10 UTC, Andrei Alexandrescu 
>> wrote:
>>> On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:
>>>> On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright 
>>>> wrote:
>>>>> C missed some obviously great ideas. One is nested 
>>>>> functions, which fit right in with C's semantics. The other 
>>>>> is the fix for:
>>>>>
>>>>> https://www.digitalmars.com/articles/C-biggest-mistake.html
>>>>
>>>> I do not think it was a mistake at all. Treating pointers 
>>>> and arrays uniformly is one of the great innovations in C.
>>>>
>>>
>> A doped pointer or hidden length would not be in the spirit of 
>> C.
>
> It would be in plain sight, the point being it's associated 
> with the pointer. Right now there's a cottage industry of 
> analysis tools figuring out which size parameter matches which 
> pointer parameter.
>
> This "no fat pointers" decision cascaded into another 
> disastruous choice - zero terminated strings. Worse than even 
> autodecoding :o).

I think it is a fallacy to think having fat pointers would solve 
anything. As I mentioned in my previous post in C there isn't a 
strong relationship between types and memory. Types are a 
convenience for manipulating memory - a piece of memory can be 
recast to any type at any time. You need a fundamentally 
different model - and that was already solved by Java in 1995.

http://www.stroustrup.com/1995_Java_whitepaper.pdf

In 1993 Dennis Ritchie said following about C arrays:

C's solution to this has real problems, and people who are 
complaining about safety definitely have a point. Nevertheless, 
C's approach has in fact lasted, and actually does work. ... You 
can't take the pure language and use it, for example, as a system 
programming language. It needs other things.

What's interesting is that in 2020 we still do not have a viable 
replacement for C. Why?

Because C's choices are necessary choices for a systems 
programming language.
If that wasn't the case everyone would just be writing programs 
in Java, C# or Go.

The real problem in my view is that people use C/C++ to write 
code they should not.