Challenge: write a reference counted slice that works as much as possible like a built-in slice

Atila Neves atila.neves at gmail.com
Tue Nov 9 18:33:01 UTC 2021


On Tuesday, 9 November 2021 at 17:26:32 UTC, Stanislav Blinov 
wrote:
> On Tuesday, 9 November 2021 at 17:15:59 UTC, Atila Neves wrote:
>
>> This is already something we're looking into it as part of the 
>> vision for D. I personally will not rest until such a library 
>> type can be written and used in @safe code. Nobody* should be 
>> calling malloc/free, just like nobody should be writing 
>> new/delete in C++14 and newer.
>>
>>
>> * Obviously for values of "nobody" that are tiny but not 
>> exactly equal to 0.
>
> Au contraire. EVERYBODY should be calling malloc/free or any 
> other allocators, including the GC. No matter how hard you try, 
> you CANNOT abstract the machine and remain a systems language 
> at the same time. If you don't want to be worrying about such 
> things, there are other, higher level, languages.

Could you please explain why you'd rather do that instead of 
using the equivalent of C++'s std::{vector, unique_ptr, 
shared_ptr} and Rust's std::{vector, unique_ptr, shared_ptr}? I 
cannot myself imagine why anyone would want to.

I think that C++'s greatest gift to the world was the destructor. 
We have those too! Let's use them.

> It's the calling of such APIs that must be made @safe.

I think the focus should be in making it possible to write the 
types I mentioned above in a @safe manner.

My advice is that unless you have a very good reason not to, just 
use the GC and call it a day.



More information about the Digitalmars-d mailing list