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