Introduce the Delete keyword

[lakani]

C# should has the ability to allocate and deallocate objects, this should be incorporation with GC, without stressing it

For example :
var clsObject = new Class1();
clsObject.Method();
delete clsObject ;

[jnm2]

What should happen if the object is deallocated while still being referenced? References to a deallocated object could end up pointing to a new or moved object of the same type (logic issues), of a different type (memory corruption), or to something random in the middle of an object (memory corruption again).

[huoyaoyuan]

C++ chooses to trust any instructions in code, introduces potentiality of wild pointer and loses safety.
Rust chooses to prove there's no other references to the object, which requires nearly a total rework of variable declaration mechanic.

Putting a deleted hole in GC heap won't increase its performance either.
If the hole isn't reused, the frequency and work of GC won't get any change. They are only affected by pages consumed by the heap, and content of alive/root objects.
If the hole is reused, finding reusable memory locations will drastically decrease the performance of allocating objects.

[lakani]

Its responsibility of developer

[theunrepentantgeek]

I remember vividly the debates around garbage collection when .Net was first previewed. (Yes, I'm that old. 😁)

The trade off is extremely cheap allocation (no need to scan lists of free memory blocks, just adjust a pointer) at the cost of an occasional scan to recover memory.

The benchmarks at the time showed that, on the average (this is important), garbage collection has less overhead per allocation and far higher safety. And this was with the GC of the time - it's gotten much better.

Yes, there are no doubt scenarios where the GC stall is a problem (such as gaming).

But: I don't think returning to manual memory management is really the answer.

[HaloFour]

Even if the runtime did add support for this there'd be no need to add a specific language feature to support it. It could be exposed as a method:

var clsObject = new Class1();
clsObject.Method();
GC.Delete(ref clsObject);

Not sure how well such a concept would work, though. At best it could be a hint if the reference happened to be the only reachable root reference. Otherwise there's no safe way to deallocate the reference.

[svick]

@lakani You can do that today: remove all references to that object and wait. Why is that insufficient for you?

[lakani]

Well , definitely for better memory management, and also if you check wasm , you will find a huge proposal for web assembly GC,
Do you think that would exists if c# provides mechanism for manually deallocate objo

[jnm2]

@lakani Why does "more manual" mean better memory management? (Also, C# didn't invent the concept of garbage collection, so yes, I would think that WASM proposal would exist either way.)

[msedi]

@HaloFour: As you said this can only be a hint for the GC. I think it might help the GC for large objects in the LOH, where the GC works a bit differently (compaction). This could help maybe in preventing

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();

[lakani]

@jnm2 well C# defiantly is not the First Language with GC, and i know well the importance of GC for developers, but i can't resist dreaming about First Perform Language, that could compete with Languages like c++ or rust , and the only path is missing "imho" is being able to manually freeing memory without GC, i know it could be a lot of hassle mixing GC code with Non GC Code, but if i'm able to write a Library that doesn't depends on GC, it would be prefect
later on the Framework itself could be written in GC free manner, and the applications could be either GC or non GC

[huoyaoyuan]

For complement:

If you want to reduce or remove the GC pressure contributed by an object, you need to change the way it's allocated, not only the way it's deleted. Once allocated onto the normal ephemeral heap, its GC pressure is already commited.

[colejohnson66]

This. If you are experiencing GC/memory pressure, your architecture is the problem, not the GC.

[CyrusNajmabadi]

I'm just going to close this out. This is such a radical change to our entire programming model that it will never happen, unless driven by unquestionable need, and massive demonstrable benefits. The OP lacks any information to motivate either.

[RedEye-Developers]

//Handle By GC

public class User
{
    public string Username;

    public void Method()
    {
        Console.Writeline(Username);
    }
}

var user = new User();
user.Method();

//Handle Manually

public interface IDeletable
{
    void Delete();
}


[Manual]
public unsafe class User : IDeletable //This Class Will not managed by GC
{
    public string Username;

    public void Method()
    {
        Console.Writeline(Username);
    }
}

var user = new User();
user.Method();
user.Delete();

//handle Manually Safty

var user = new User();
user.Method();
user.Delete();
user.Method(); //Compail Time Error.

we can do like this right ?

i am expecting cs like need more control over memory from memory intensive applications.
for non-memory optimized related work automatic GC good for code fast and secure.

in cs more memory control + automatic was i feel good.

because we can mix both and make a good memory performance applications i think so.

[huoyaoyuan]

No. A "class" is depending everything about GC. To avoid GC, it must be a struct instead of class.

i am expecting cs like need more control over memory from memory intensive applications.

C# doesn't control memory. It's .NET runtime controlling memory.
Manual memory control is usually worse. With dotnet/runtime#115627, the pain will be reduced further.

[RedEye-Developers]

No. A "class" is depending everything about GC. To avoid GC, it must be a struct instead of class.

but a struct only under 16 bytes is recommended for optimal performance.

[HaloFour]

but a struct only under 16 bytes is recommended for optimal performance.

Only if you plan to copy it by value. If you pass the struct around by reference it's no different than passing a class reference.

[HaloFour]

we can do like this right ?

No, there's simply no safe way to do this. A reference to that instance could have been shared and neither the compiler nor the runtime would know that it's actually safe to deallocate that instance without actually going through a garbage collection cycle, which would instantly make trying to do so much more expensive. The compiler also could not actually check any of those other references, which would now point to garbage and have undefined behavior at runtime.

var user = new User();
List<User> users = [user];
user.Method();
user.Delete();

// somewhere else
var otherUser = users[0]; // compiler has no idea
otherUser.Method(); // Very bad things happen here