On 29/05/2022 12:26 PM, deadalnix wrote:
> Yes, this is a good start. You have one major missing point: you need something to transfers ownership or you end up very limited.

Can you please write up an example similar to what I wrote, so that we can see what would be added (my mind just go blank on that paper)?

On 29.05.2022 03:26, deadalnix wrote:
> Yes, this is a good start. You have one major missing point: you need something to transfers ownership or you end up very limited.
> 
> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/msr-tr-2012-79.pdf 
> 
> 
> All we need is one god damn type qualifier and we make DIP1000, @live, RC object, nogc exception and couple of other long standing problem a thing of the past.

You mean `isolated`? Funny but we almost have this type qualifier - in fact it is opposite/antonym to `shared`, I guess.

On 29/05/2022 7:42 PM, Ola Fosheim Grøstad wrote:
> Maybe look at the basic ideas for static analysis? Then you will know the limitations.
> 
> How do you deal with conditionals?

```d
Thing func(Thing a, Thing b, bool pickB) {
	return pickB ? a : b; // ownership: [a, b]
}
```

> How do you deal with mutable arrays of pointers?

```d

void func(Thing a, Thing b) {
	int[] arr; // ownership: []
	
	arr ~= a; // arr ownership: [a]
	arr ~= b; // arr ownership: [a, b]

	arr = arr[0 .. 1]; // arr ownership: [a, b]
	arr ~= b; // arr ownership: [a, b]
}
```

> Simple stuff like a queue of size two? How do you know what it contains?

See above

> With lifetimes you can be pessimitic: max lifetime of anything that could in theory be put into it unless I am able to prove otherwise. Then you dont have to try to prove something unless it is needed.
> 
> Better to just add ARC and do all these things as optimizations.

I too would like to have proper reference counting on structs and classes with optimizations, but the compiler has to know what object to do the reference counting on! Right now things can escape reference counting.

On 29/05/2022 7:57 PM, Ola Fosheim Grøstad wrote:
> On Sunday, 29 May 2022 at 07:42:29 UTC, Ola Fosheim Grøstad wrote:
>> Maybe look at the basic ideas for static analysis? Then you will know the limitations.
> 
> Think of it like this:
> 
> If you try to be precise then parts of it has to happen at runtime.
> 
> If you want to do it at compile time then you have to overapproximate (be more pessimistic than the possible runtime situations).

My goals for this was to be a very cheap set of checks at compile time, that can catch most naive wrong life time issues, while being easily explained.

I'm not concerned too much about preciseness as long as the false positives are low (or at least lower than DIP1000).

On 29/05/2022 7:42 PM, Ola Fosheim Grøstad wrote:
> Simple stuff like a queue of size two? How do you know what it contains?

I've been thinking back on my past thought experiments, how I use to turn this on was with scope as a type qualifier.

For non-owning data structures like queues, you would never intentionally mark that as scope since its entries will always have separate lifetimes from that of the data structure itself.

So even if implemented, this may not be a general solution that we are looking for.