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

[Nicholas Wilson]

On Tuesday, 12 November 2019 at 09:12:51 UTC, Robert Schadek 
wrote:
> On Monday, 11 November 2019 at 22:28:05 UTC, Walter Bright 
> wrote:
>> Although malloc() is marked as @system, it actually is @safe. 
>> It's free() that needs to be @system.
>
> I think that is a mute point.

(You mean moot point)

> malloc gives you a void*, you can't really do anything with 
> that void*
> in @safe code.
> You can't even cast it to int*, and it shouldn't.
>
> I know I sound like a broken record, but IMO mmm and @safe is 
> the wrong direction.

Thats what containers are for, to encapsulate the inherent 
unsafety and expose a safe interface.

> Generative programming in combination with functional 
> programming, is
> awesome. Hardly anybody is doing that.
> I'm not saying we should steal other peoples good ideas.
> I'm trying to say we should steal interesting ideas/mistakes 
> and improve on them.

We should definitely steal them, but we had better a) make sure 
they are good ideas, and b) understand what makes them good. 
Otherwise we risk doing what C++ did with static if/constexpr if, 
UFCS and many more.

> For instance taking the c++ template meta-programming mistake 
> and
> making it a feature was a huge win.
>
> Additionally, I think there is an elephant in the room. 
> Multi-threading.
> I just watched a talk on rust async/await.
> https://www.youtube.com/watch?v=lJ3NC-R3gSI
> It took them ~10 years to get the borrow-checker + multi 
> threading thing
> done/right, and compared to us they have infinite resources.
> Is there a plan for D and the borrow-checker in place/planning?

That would be DIP1024[1], which follows the same proof of safety 
by induction of @trusted leaf functions for encapsulating safe 
access to members with locks/atomics/etc.

[1]:https://github.com/dlang/DIPs/blob/master/DIPs/DIP1024.md