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

[H. S. Teoh]

On Tue, Nov 09, 2021 at 05:26:32PM +0000, Stanislav Blinov via Digitalmars-d 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.

I think Atila's point is that *by default* you should be able to write
high-level D code without needing to call malloc/free, but when
necessary, you can do so *and* still take advantage of the high-level
abstractions of the language (e.g., maintain @safe-ty, etc.).


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

IMO, that's not possible. In general code that calls malloc/free it's
not possible to prove anything @safe. The only way you can do this in a
waterproof way is to implement the equivalent of GC tracing at
*compile-time* so that every call to free() can be proven to happen
exactly once for every call to malloc(). This is obviously impossible.

In general, it's a mistake to mark malloc/free as @safe or pure, it's
the wrong semantics and will only lead to trouble down the road.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you fail to deliver after.