DIP 1025--Dynamic Arrays Only Shrink, Never Grow--Community Review Round 1

[Jab]

On Tuesday, 12 November 2019 at 00:51:28 UTC, Walter Bright wrote:
> On 11/11/2019 2:33 PM, Paolo Invernizzi wrote:
>> On Monday, 11 November 2019 at 22:28:05 UTC, Walter Bright 
>> wrote:
>> 
>>> We either get on the bus or get run over by the bus.
>> 
>> Frankly speaking, I've read such argumentations a lot of times 
>> along many years in the D history: the concurrency chapter of 
>> the D Programming Language is here to testify that this type 
>> of argumentation should be avoided, in a technical discussion.
>> 
>> Let's move forward from that, and let's try to find a sound 
>> solution to the memory safety problem, but without killing the 
>> language in the attempt.
>> 
>> There's no hurry: D is _already_ a safe language, thanks to 
>> your intuition of 20 years ago to bake the GC.
>
> D is quite a bit safer currently than C or C++, but we've been 
> a bit complacent about that advantage and are at risk of 
> falling behind.
>
> I am replying to the question about what is the direction D is 
> going. This is the direction and the motivation for it. Whether 
> DIP 1025 is the correct move in that direction or not is 
> certainly worthy of technical discussion.
>
> BTW, after not having memory corruption bugs for years, I've 
> lost days of work in the last couple months looking for the 
> cause of two memory corruption problems in DMD.

How have you not had this problem before? DMD's code base is kind 
of horrible. Pointers to arrays that end up having to be accessed 
by (*p)[x]. A simple wrapper could easily have alleviated that 
entirely. It's kind of ironic that the D reference compiler 
showcases exactly how you shouldn't write D code.

> I had grown complacent.

And now you are over eager to make changes to change that 
complacency. These DIPs are being ejected out one after another. 
It seems like everything else is being thrown under the bus on 
this hellbent pursuit of safety.

> ... the former at compile time and the latter at runtime (as a 
> dynamic check is necessary). Hence, a long deprecation period 
> will be necessary.

Of all the things people would be willing to have such a big 
breaking changes for. Auto-decoding to name one. This is now 
where the line is drawn? Some of these decisions are being made 
too hastily IMO.