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.

On Tuesday, 9 November 2021 at 18:16:03 UTC, H. S. Teoh wrote:

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

Oh, I understand the sentiment, I really do. That we need more out-of-the-box tried and true robust containers is not in question - hence the premise of this very topic by Andrei. It's this constant desire to "abstract away" the very things that you literally *need* to operate on that puzzles me. Hey, raw pointers are bad, don't use! Hey, "new" is bad, don't call! Well if you're not using raw pointers and you aren't calling "new", there's Python. Or something. You don't get to keep the performance, and power, of low level languages, if you desperately abstract everything away. "Zero-cost" abstractions aren't a thing, it's a buzzword myth.

>
>> 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(). At least, I think it could be:

while (true)
{
    auto a = alloc.allocate(1);
    auto b = alloc.allocate(100500);
    // ...

    // if here you can prove that nothing escaped, the call is safe.
    // which means `allocate` needs to paint the result somehow.
    alloc.freeAll();
}

Yip, that is, effectively, manual GC.

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

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.

On 09.11.21 18:26, Stanislav Blinov wrote:
> 
> It's the calling of such APIs that must be made @safe. Walter is attempting just that with @live.

This is not true.

> Incidentally, if THAT is made possible, you will be able to have the cake and eat it too.

But we are on the same page here.