On 2021-11-05 9:45, deadalnix wrote:
> On Friday, 5 November 2021 at 09:43:21 UTC, Dukc wrote:
>> On Friday, 5 November 2021 at 03:12:39 UTC, deadalnix wrote:
>>> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>>>> https://github.com/dlang/phobos/pull/8309
>>>>
>>>> Destroy!
>>>
>>> I'm highly skeptical of making phobos 2 at this time. Maybe I'm wrong, but we discussed it not so long ago, and I tried to work on collections for it.
>>>
>>> Problem is: it is not possible, as far as I can tell, to write a high quality collection library in D right now.
>>
>> That is an orthogonal problem. If we agreed to merge some collections library to Phobos, it could be done to Phobos 1 just as well. We don't need Phobos 2 for that.
>>
> 
> No it is not.
> 
> The reason for which phobos v1 does not have a good set of collection have not changed, and therefore phobos v2 will not have a good set of collections.
> 
> Range have the exact same problem.

Versioning and safe pure nogc reference counting (which is the true problem with implementing containers in D) are largely orthogonal. Or I should say just distinct, as "orthogonal" is unnecessarily precise.

We never got reference counting to work in safe pure nogc code. And we don't know how. If we did, we could write a slice-like type that does everything a slice does PLUS manages its own memory. This is the real problem with containers.

On Friday, 5 November 2021 at 14:08:58 UTC, Andrei Alexandrescu wrote:
> We never got reference counting to work in safe pure nogc code. And we don't know how. If we did, we could write a slice-like type that does everything a slice does PLUS manages its own memory. This is the real problem with containers.

I'm pretty sure at least some of us (including Atila) know how.

In order to manually free memory in @safe code, you need a way to guarantee that the memory is not aliased. To do that, you either need runtime checks or compile-time checks. Runtime checks are possible in the current D language, but compile-time checks are not. So, if we want @safe @nogc containers without runtime overhead, a new language feature is required.

Unfortunately @live will not help with this, because it is possible (by design!) for @safe code to violate the invariants of @live.

One idea that's come up recently in the community Discord is a `unique(T)` qualifier, which would guarantee that any memory reachable via indirections in a given `T` value is not aliased. Exactly how to enforce this is an open question.

On Friday, 5 November 2021 at 15:06:58 UTC, Paul Backus wrote:
> On Friday, 5 November 2021 at 14:08:58 UTC, Andrei Alexandrescu wrote:
>> [snip]
> One idea that's come up recently in the community Discord is a `unique(T)` qualifier, which would guarantee that any memory reachable via indirections in a given `T` value is not aliased. Exactly how to enforce this is an open question.

That's a new idea? I'm pretty sure there were a few people who have been saying something like that for a while. It's like putting @live into the type system.

On Friday, 5 November 2021 at 15:33:22 UTC, jmh530 wrote:
> On Friday, 5 November 2021 at 15:06:58 UTC, Paul Backus wrote:
>> One idea that's come up recently in the community Discord is a `unique(T)` qualifier, which would guarantee that any memory reachable via indirections in a given `T` value is not aliased. Exactly how to enforce this is an open question.
>
> That's a new idea? I'm pretty sure there were a few people who have been saying something like that for a while. It's like putting @live into the type system.

Vibe needed more than one grade of it: https://vibed.org/api/search?q=isolated

On 2021-11-05 11:06, Paul Backus wrote:
> On Friday, 5 November 2021 at 14:08:58 UTC, Andrei Alexandrescu wrote:
>> We never got reference counting to work in safe pure nogc code. And we don't know how. If we did, we could write a slice-like type that does everything a slice does PLUS manages its own memory. This is the real problem with containers.
> 
> I'm pretty sure at least some of us (including Atila) know how.

Please post the code, thanks!

Main problem is getting reference counting to work reliably in the presence of purity and immutability.

On Friday, 5 November 2021 at 15:06:58 UTC, Paul Backus wrote:
> One idea that's come up recently in the community Discord is a `unique(T)` qualifier, which would guarantee that any memory reachable via indirections in a given `T` value is not aliased. Exactly how to enforce this is an open question.

Yes. I would love to be able to express that an object has only one reference to it, as well as being able to express that requirement on arguments (which is like two sides of the same coin). The uniqueness doesn't always necessarily have to hold forever for it to be useful too.

On Friday, 5 November 2021 at 15:06:58 UTC, Paul Backus wrote:
> One idea that's come up recently in the community Discord is a `unique(T)` qualifier, which would guarantee that any memory reachable via indirections in a given `T` value is not aliased. Exactly how to enforce this is an open question.

Here you go: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/msr-tr-2012-79.pdf

Unique is a bad name, because it doesn't have to be unique, it needs to be a unique entry point to a subgraph of objects, but there can be objects within the graph pointing back at the root.

If you go back to my old post about isolated and owned, you can find a lot of infos about this.

I'm a bit disappointed though, because I gather from your message that the idea is still new for most around here. It solves so many of D's problem that it's not even funny, but instead we got a numerous features that don't quite work (@nogc, DIP1000, @live, ...).

I'm glad there is some renewed interest about this. This is such an obvious fit for D.

On Friday, 5 November 2021 at 17:33:54 UTC, Andrei Alexandrescu wrote:
> On 2021-11-05 11:06, Paul Backus wrote:
>> On Friday, 5 November 2021 at 14:08:58 UTC, Andrei Alexandrescu wrote:
>>> We never got reference counting to work in safe pure nogc code. And we don't know how. If we did, we could write a slice-like type that does everything a slice does PLUS manages its own memory. This is the real problem with containers.
>> 
>> I'm pretty sure at least some of us (including Atila) know how.
>
> Please post the code, thanks!
>
> Main problem is getting reference counting to work reliably in the presence of purity and immutability.

That and preventing the this pointer from escaping.

On Saturday, 6 November 2021 at 01:45:45 UTC, deadalnix wrote:
> On Friday, 5 November 2021 at 17:33:54 UTC, Andrei Alexandrescu wrote:
>> On 2021-11-05 11:06, Paul Backus wrote:
>>> On Friday, 5 November 2021 at 14:08:58 UTC, Andrei Alexandrescu wrote:
>>>> We never got reference counting to work in safe pure nogc code. And we don't know how. If we did, we could write a slice-like type that does everything a slice does PLUS manages its own memory. This is the real problem with containers.
>>> 
>>> I'm pretty sure at least some of us (including Atila) know how.
>>
>> Please post the code, thanks!
>>
>> Main problem is getting reference counting to work reliably in the presence of purity and immutability.
>
> That and preventing the this pointer from escaping.

Unless I'm missing something, `scope` and dip1000 cover that.

On Monday, 8 November 2021 at 14:01:18 UTC, Atila Neves wrote:
> On Saturday, 6 November 2021 at 01:45:45 UTC, deadalnix wrote:
>> On Friday, 5 November 2021 at 17:33:54 UTC, Andrei Alexandrescu wrote:
>>> On 2021-11-05 11:06, Paul Backus wrote:
>>>> On Friday, 5 November 2021 at 14:08:58 UTC, Andrei Alexandrescu wrote:
>>>>> We never got reference counting to work in safe pure nogc code. And we don't know how. If we did, we could write a slice-like type that does everything a slice does PLUS manages its own memory. This is the real problem with containers.
>>>> 
>>>> I'm pretty sure at least some of us (including Atila) know how.
>>>
>>> Please post the code, thanks!
>>>
>>> Main problem is getting reference counting to work reliably in the presence of purity and immutability.
>>
>> That and preventing the this pointer from escaping.
>
> Unless I'm missing something, `scope` and dip1000 cover that.

Which he covered in his message here:

> but instead we got a numerous features that don't quite work (@nogc, DIP1000, @live, ...).