On 5/3/22 22:37, forkit wrote:

> In any case, I disagree that caring about when memory gets deallocted
> means you shouldn't be using GC. (or did I get that one wrong too??)

At least I don't agree with you there. :) Yes, one should not care about how memory gets freed if one did not care how that memory was allocated.

> You can have the best of both worlds, surely (and easily).

There are always many subtleties.

> This (example from first post):
>
> void main(){
>      int[] i = new int[10000];
>
>      import object: destroy;
>      destroy(i);
>      import core.memory: GC;
>      GC.free(GC.addrOf(cast(void *)(i.ptr)));
> }

So is this about that simplest case?

1) We know the number of elements up front.

2) The elements are simple like 'int' that there is no separate allocation for each?

If so, I don't think adding a language feature is necessary for this narrow case.

Note: To answer a related question: I haven't designed or implemented any language, haven't contributed to any compiler, etc. I have no strong say on D or any other language. I am just a user who disagrees with the request in this thread.

> could (in theory) be replaced with this:
>
> void main(){
>      inscope int[] i = new int[10000];
>
>      // inscope means 2 things:
>      // (1) i cannot be referenced anywhere except within this scope.
>      // (2) i *will* be GC'd when this scope ends

If this feature was for more complicated examples as well, i.e. if we added new elements ever, there might be multiple memory allocations by the GC. Are we concerned only about the very last one? So, allocations 0, 1, .. N-1 can be left to the GC but allocation N must be freed now?

If not, should the GC keep a list of allocations for each 'inscope' object? (Is this only for arrays? What about potentially multiple allocations for a single object throughout its lifetime?)

What about that list itself? :) Should that be allocated from the GC and be 'inscope' as well?

There must be other questions that I miss. What I am sure is, somebody in the future will be unhappy how 'inscope' is implemented for their case and will propose another feature on top of it. I think it is better to leave such special decisions to the programmer.

Again though, I would be happy to be corrected.

Ali

On Wednesday, 4 May 2022 at 12:57:26 UTC, Ali Çehreli wrote:
> On 5/3/22 22:37, forkit wrote:
>
> > In any case, I disagree that caring about when memory gets
> deallocted
> > means you shouldn't be using GC. (or did I get that one wrong
> too??)
>
> At least I don't agree with you there. :) Yes, one should not care about how memory gets freed if one did not care how that memory was allocated.
> ....

That languages with GC typically give the programmer some control over the GC, is evidence that programmers do care (otherwise such features would not be needed).

To deny a programmer the option to release the memory that was GC allocated within a particular scope, to be release immediately after that scope exits, seems kinda cruel.

To force a programmer to run a full GC in such a situation, is also kinda cruel.

To force a programmer back to using the ancient malloc/free.... well.. that's even crueler.

On Wed, May 04, 2022 at 09:46:50PM +0000, forkit via Digitalmars-d-learn wrote: [...]
> That languages with GC typically give the programmer some control over the GC, is evidence that programmers do care (otherwise such features would not be needed).
> 
> To deny a programmer the option to release the memory that was GC allocated within a particular scope, to be release immediately after that scope exits, seems kinda cruel.
[...]

	scope ptr = GC.malloc(size);
	scope(exit) GC.free(ptr);

	... // use ptr however you like until end of scope


T

-- 
It's amazing how careful choice of punctuation can leave you hanging:

On Wednesday, 4 May 2022 at 15:04:13 UTC, cc wrote:
> The MemUtils package offers a `ScopedPool` utility that seems interesting.  It isn't well documented however so I have no idea if it actually works like I expect.  I presume this would work something akin to a VM memory snapshot/rollback for the GC?  It would be pretty handy for some scenarios, say a serialization library.  You specify a snapshot point (add a pool to the stack?), incur all your GC allocations necessary for generating the structure of your serialized data (which go into the pool instead of the GC proper?), then you write it to disk and pop the stack, effectively rolling back to the original memory state of your program's GC.  As long as you make sure not to leak anything allocated within that phase, seems like a good deal.
>
> https://code.dlang.org/packages/memutils

Interesting.

My idea was ... objects marked as 'inscope' would be GC allocated in a LIFO region of the heap, rather than the general GC pool.

Explicately deallocating such objects at end of scope then becomes a no brainer for the GC (since 'inscope' would ensure at compile time that no pointers/aliasing outside of that scope could exist).

The LIFO would also avoid the problem of fragmentation (i.e. if the objects were allocated in the general GC pool instead of a separate pool).

This would give the programmer 'scope-based deallocation of GC allocated memory'.

On Wednesday, 4 May 2022 at 21:55:18 UTC, H. S. Teoh wrote:
> On Wed, May 04, 2022 at 09:46:50PM +0000, forkit via Digitalmars-d-learn wrote: [...]
>> That languages with GC typically give the programmer some control over the GC, is evidence that programmers do care (otherwise such features would not be needed).
>> 
>> To deny a programmer the option to release the memory that was GC allocated within a particular scope, to be release immediately after that scope exits, seems kinda cruel.
> [...]
>
> 	scope ptr = GC.malloc(size);
> 	scope(exit) GC.free(ptr);
>
> 	... // use ptr however you like until end of scope
>
>
> T

that's cruel!

I just want 'scope-based deallocation of GC allocated memory'.

I just want to write one word for this to happen -> 'inscope'

On Wed, May 04, 2022 at 10:04:53PM +0000, forkit via Digitalmars-d-learn wrote:
> On Wednesday, 4 May 2022 at 21:55:18 UTC, H. S. Teoh wrote:
> > On Wed, May 04, 2022 at 09:46:50PM +0000, forkit via Digitalmars-d-learn wrote: [...]
[...]
> > > To deny a programmer the option to release the memory that was GC allocated within a particular scope, to be release immediately after that scope exits, seems kinda cruel.
> > [...]
> > 
> > 	scope ptr = GC.malloc(size);
> > 	scope(exit) GC.free(ptr);
> > 
> > 	... // use ptr however you like until end of scope
[...]
> that's cruel!
> 
> I just want 'scope-based deallocation of GC allocated memory'.
> 
> I just want to write one word for this to happen -> 'inscope'

-------
import std;

// Put this in some common module
auto scoped(T, Args...)(Args args) {
	static struct Result {
		private T* payload;
		ref T get() { return *payload; }
		alias get this;
		~this() {
			import core.memory : GC;
			writeln("dtor");
			GC.free(payload);
		}
	}
	return Result(new T(args));
}

// Then you can use it in just a single line, as below
void main() {
	struct MyType {
		int blah, blahblah;
	}

	auto data = scoped!MyType(10, 20);  // <--- like this
	data.blah = 123; // use data as you like

	// automatically frees on scope exit
}
-------


T

-- 
Тише едешь, дальше будешь.