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

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Nov 9 20:23:08 UTC 2021


On Tue, Nov 09, 2021 at 07:57:21PM +0000, Stanislav Blinov via Digitalmars-d wrote:
> On Tuesday, 9 November 2021 at 18:16:03 UTC, H. S. Teoh wrote:
[...]
> > > 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.
> 
> Could be possible for allocators that don't need a free() for every
> malloc().

Yes, but then you're back to malloc/free (well, the C version of it)
being inherently @system, and there is no way you can make them @safe.


[...]
> > 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.
> 
> But if you can express ownership in the language, it should be
> possible to make at least a @safe interface to them.

To be able to express ownership to the extent that you can do this, is
basically equivalent to importing Rust into D. Is that really what we
want to do?


T

-- 
It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.


More information about the Digitalmars-d mailing list