By ref and by pointer kills performance.

[Richard (Rikki) Andrew Cattermole]

On 19/02/2024 2:58 AM, max haughton wrote:
> Thinking about it, it's actually probably mainly an issue for library 
> users rather than the author who actually wrote restrict to begin with - 
> I have wondered in the past whether some kind of |isolated| style type 
> qualifier could actually help here i.e. one could provide the compiler 
> good information and make it very obvious to the programmer.

A couple of days ago I had a read of Joe Duffy's blog.

I was very impressed with what he had to say, enough to immediately want 
to buy his concurrency book and start adding his blog articles as 
references to my existing proposals.

He was one of the developers Midori and had a lot to say about exception 
mechanisms and concurrency. Turns out we both have some similar 
conclusions, only he gained his about 15 years prior to me (which may or 
may not have contributed to my impression).

The concept of isolated was one such concept that he talked about in 
regards to concurrency and its safety. I had not thought about it, that 
it would be a useful tool for making memory ownership safe in this context.

But it also applies here consider:

```d
isolated(int[]) a, b;
func(a, b);

void func(scope int[] c, scope int[] d) @safe {}
```

Should that be callable with a and b? Yes. The graph doesn't matter, it 
doesn't escape.

Now what about the case where it does?

```d
int[] func(return scope int[] c, scope int[] d) @safe {
	return c;
}
```

Again yes. Only one parameter contributes to return, the return would 
therefore be part of ``a``'s graph.

Another interesting possibility is that if one parameter is isolated, 
that means the second parameter ``d`` is not in ``c``'s graph, because 
isolated is a form of transfer of ownership, except because ``c`` is 
scope, the transfer doesn't occur from the outside.

As a result both ``c`` and ``d`` would have ``@restrict`` added.

This is on my todo list to research, of course how exactly it plays out 
with DIP1000 and the this pointer is unknown to me at this stage.