Type state analysis

[Richard (Rikki) Andrew Cattermole]

On 11/04/2024 7:31 AM, Atila Neves wrote:
> On Wednesday, 10 April 2024 at 19:23:17 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> Yes, because of the explicit scope creation. The compiler can see it 
>> cross scopes, but not within a scope this requires tracking of values 
>> and their order of invalidation.
> 
> Unless I'm missing something, that's exactly what DIP1000 does? How else 
> would "order of invalidation" work except through scopes? Explicit 
> destruction? Why do that??

See my earlier example:

```d
Parent* parent;
Field* child = &parent.field;
parent.destroy;
Field value = *child;
```

That simply shouldn't compile.

One single scope, and it absolutely should be under DIP1000's purview.

This is critical for owning data structures (which can include memory 
allocators) for it to be solved.

Note: destruction also includes assignments to the variable that had 
contained the data structure.

```d
DS ds = ...;
Item* item = ds[...];
ds = ...;
Item value = *item;
```

Same exact pattern.

>>> It's the same reason why I don't understand "Logic errors such as 
>>> trying to read from an unopened file" - why would a file be unopened?
>>
>> Accidental, different scope states (conditional/function calls),
> 
> What would an example of that look like?

```d
mayCloseOnSpecificInput(file);

file.read(); // may or may not be closed
```

Add an if/else block to it as well, well... Fun.

>> explicit closing
> 
> Doctor, doctor, it hurts when...

And like goto's we don't allow you to skip variable declarations.

Don't explicitly close and not handle the branches correctly.

Doesn't mean we shouldn't have compiler assistance to prevent you from 
making this mistake.

>> , events handled automatically by OS.
> 
> Example?

For a socket, peer closed connection. A normally occurring event, that 
kills the handle automaticaly.

>> A lot of reasons.
> 
> I haven't encountered any; I'm not saying they don't exist, I'm saying 
> that in my experience they're rare enough that they're approximately 
> zero. I don't think that's ever happened since I stopped writing C. If 
> one creates a file, it's open. If the file is no longer in scope, it's 
> closed.

For context: a file representation is the classic example from the 80's 
for type state analysis. However there was a giant thread only a couple 
weeks back wanting nullability type state checks.

Notice how a lot of languages now have nullability analysis in them? 
Yeah. That would be a much better example from a practical stand point.