September 18

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

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

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