An idea for GC and freeing of resources without finalization

[Ola Fosheim Grøstad]

On Thursday, 17 June 2021 at 11:14:05 UTC, rikki cattermole wrote:
> Having the GC act as a backup wouldn't be a bad thing!

Exactly, if it is there anyway, why not use it?

> More complex patterns shouldn't matter. Once you have an owning 
> point on the stack, which may not be explicitly known (as long 
> as the scope rules are meet, you should be able to figure it 
> out locally).

That won't work if you have many async connections. Then they are 
stored in a graph on the heap. My goal is to get rid of the need 
for finalizers and destructors, to speed up collection and make 
code easier to write.

So, for instance, if a fileobject is constructed with the file 
path and then has an open() and close() method. Then you could in 
Python-like fashion do something like

```
with Url("some/path/file.txt") as f {
     … f.read() …
}
````

Which basically calls f.open() then waits for the data to be 
ready and continues, then calls f.close().

Or you could

```
store_on_heap_read_when_ready(Url("some/path/file.txt").open())

```

Not necessarily this syntax, but you get the idea.