On Monday, 23 January 2023 at 17:49:20 UTC, Richard (Rikki) Andrew Cattermole wrote:

struct Thing(T) {
	ref T get() scope { ... }
}

{
	Thing thing;
	scope ref got = thing.get; // owner = thing
	func(got); // ok parameter is scope

	thing = Thing.init;// Error: thing must out live got variable, but thing is being assigned to.
	return got; // Error: scope variable thing must out live got variable, but got is being returned.
}

void func(scope ref T value) {}

I'm afraid it's more complicated than you think.

thing might have its destructor called before the end of got lifetime. The language could pretty trivially prevent doing that directly, but what if you have a scope pointer to thing and call the destructor via it? or a scope SumType!(Thing*, int*)[5] variable, that may contain both references to both things and ints?

These are probably solvable, but the solution is going to be at least as complex as @live, if not more so.

On Monday, 23 January 2023 at 17:44:03 UTC, Paul Backus wrote:

Now when I think of it, it probably should be called an allocator certificate and used for all allocators. @trusted required only if any of the other allocation primitives are @system. We have no reason to support allocators which might corrupt memory if they free their own memory after all, so no reason to name the certificate after reference counting.

Anyway, what's the problem? Perhaps we can improve this solution somehow. I agree with you that we do not want to wait for any major language-level changes, considering how long it took for DIP1000 to become stable.

On Tuesday, 24 January 2023 at 14:51:06 UTC, Dukc wrote:

Also I suspect the benefit-to-complexity ration of isolated or a complete borrow checker would be poor. It fits Rust, since it's a dedicated systems programming language. D is an application programming and scripting language as much as it's a systems language, so for us it isn't as good fit.

After all, GC solves the majority of memory safety issues already, and DIP1000 can solve a big part, if not the majority of what isn't solved by the GC.

On Tuesday, 24 January 2023 at 15:03:46 UTC, Dukc wrote:

It's worth noting that D already has a bunch of special-case language rules that would be unified by adding isolated.

For example: return values of so-called "Pure factory functions" are allowed to implicitly convert to immutable, because "all mutable memory returned by the call cannot be referenced by any other part of the program"--or, in other words, the return value is isolated.

There's a similar rule for new expressions, although it doesn't seem to be written down anywhere. You can see it at work in code like this:

// converts from mutable to immutable
immutable(int[][]) a = new int[][](3, 3);

Replacing all of these special cases with a single consistent set of rules would help simplify the language.

On Tuesday, 24 January 2023 at 16:11:00 UTC, Paul Backus wrote:

That's precisely what made the bottom type such a great DIP from the perspective of use. However, as with the bottom type, it isn't any easier to write the DIP nor implement nor debug it. Meaning, in the long run we might well want isolated, but allocator-aware reference counter should not be waiting for one - which I think is what you said.

On Tuesday, 24 January 2023 at 16:21:37 UTC, Dukc wrote:

Oh sorry, I remembered Paul's earlier post wrong. He wrote:

..but that was referring to the borrow function, not allocators.

On Sunday, 22 January 2023 at 21:11:31 UTC, RTM wrote:

From the @live docs:

AFAIU isolated needs to guarantee no other references point to the data, so that we can call free on it without dangling references. That applies even if the data is immutable, so we can put immutable data on the heap.

On Tuesday, 24 January 2023 at 21:01:04 UTC, Nick Treleaven wrote:

I would think that a hypothetical isolated would apply to mutable data or pointers to mutable data. If the data is const or immutable, then D's transitivity implies that all pointers to it are read only.