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

[Stanislav Blinov]

On Tuesday, 9 November 2021 at 18:33:01 UTC, Atila Neves wrote:
> 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.

Instead? Not instead. Together with. It's all well and fine to 
rely on proven library solutions. But I'd rather a D or C++ 
programmer, when faced with necessity, be able to write their 
allocations correctly, and not hide under a rug because 
Herb'n'Scott tell 'em that's "bad practice".

We already have at least two (three?) generations of programmers 
who literally have no clue where memory comes from. If we keep 
this up, in a couple decades "nobody" (your definition of nobody) 
would be able to write you a better malloc for your next 
generation of platforms and hardware.

Take a peek in the learn section. Person asks how to translate a 
simple C program into D. Buncha answers that *all* amount to 
"allocate craptons of memory for no reason". At least one from a 
very well known D educator. Only no one even mentions any 
allocations at all. Why even talk about it, right? That array 
just sort of happens out of nowhere...

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

Yeah, we have them. And the GC may call them. Any time you 
allocate it may call them. Even if they aren't pure or safe. But 
hey, that's OK between friends.

>> 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.

Who, using a SYSTEMS language, should not have a reason to care 
about their memory? I can think of literally just one case: 
needing a quick script and being too lazy to switch to something 
other than D just for that.