• Richard (Rikki) Andrew Cattermole (51/51) Sep 18 After this month's monthly meeting, me and Walter had a chance to
• Richard (Rikki) Andrew Cattermole (22/22) Sep 23 I think it is time to bump this as there hasn't been any replies in four...

Richard (Rikki) Andrew Cattermole <richard cattermole.co.nz> writes:

After this month's monthly meeting, me and Walter had a chance to 
talk briefly about how to go forward on my escape analysis 
proposal. What I was able to conclude, is that Walter was unable 
to understand the subtle changes between that proposal and 
DIP1000.

So what this proposal is meant to do, is to demonstrate just how 
different it is and quite importantly it introduces modifiers on 
a given input-output relationship. This establishes how memory 
moves within a function.

A key difference in this analysis framework is that DIP1000 
considers the attributes at the start of analysis, this one does 
not. It can grow and shrink as analysis occurs and errors happen 
as late as possible allowing for more code to work AND with a 
second forward pass enables a traced set of errors rather than 
just when the error occurs.

Inferred everything of course. But inferration is a side effect 
of validation.

Latest: 
https://gist.github.com/rikkimax/18563106f610a2daa069c635079a955c

Current: 
https://gist.github.com/rikkimax/18563106f610a2daa069c635079a955c/13f84866c82d66dacd9a32039e96cb4aa0243a1f

There are two examples where the relationship modifiers defaults 
are not what you want, the defaults are setup to eliminate the 
``return scope`` ``scope return`` ordering issues. Of note is 
that ``return`` can be mapped to `` escape(return)`` and 
``scope`` to `` escape()``.

```d
// default strength would be = due to return not being ref, but 
we want it &
int** intRefOutPtr( escape(return&) ref int* input) => &input;

struct Owner {
	private {
		int* ptr;
	}

	int* borrow()  escape(return&) {
		return this.ptr; // default strength for return would be . but 
we want &
	}
}
```

The benefit of this proposal as the framework for escape 
analysis, is owner escape analysis (borrow checker) can always be 
on. DIP1000 has a subset of this that is specialized to stack 
memory. GC memory would not be affected unjustly. This allows us 
to have safe reference counting and therefore they would be 
unblocked.

Another benefit is type state analysis (nullability) would be 
able to be performed at the same time. It uses the same state 
storage as escape analysis and hooks the same or similar things 
so it will be fairly cheap. This too opens up a new feature, an 
ownership transfer system like isolated ala Midori.

"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:

I think it is time to bump this as there hasn't been any replies in four 
days.

Right now, this will be the proposal I'll take to development (some 
minor modifications locally).

It solves issues of DIP1000 by:

- Multiple outputs.
- Replace the abomination that is DIP1000 attributes, with clear 
differentiation between where to escape to and what the relationship is.
- Inferred attributes.
- Will give better error messages.
- Allow escape set to grow then shrink down before erroring (more code 
will be valid, that is valid).
- Tuple-like variables will have their lifetimes of each element tracked 
separately.
- Reference counting is describable, and therefore can be made safe, is 
unblocked.

All of the above features are things people have had issues with 
DIP1000, replacing the framework that the analysis works in should 
resolve all of the design level issues with it (at least the ones I can 
think of that are reasonable to fix).

It has a nice side effect of offering the framework needed for type 
state analysis at very little additional cost to it.