[FEATURE] Add resource management operators `forget` and `drop`

[davidscholberg]

I've got an idea for a couple of semi-related operators that could improve resource ergonomics.

The first one allows a variable to be "forgotten" such that Zen C will not attempt to call the drop method on it, nor allow it to be used further in the scope in which it is defined. This would be primarily useful if you needed to transfer some resource to a variable of a different type, e.g.:

let b = Bar::new();

// do some stuff with b

let f = Foo::new();
f.x = b.y;
forget b;

// now f owns the resource that b previously owned, and b can no longer be used

The second operator is related to forget but goes a step further; it would immediately call the drop method on the variable, and (like forget) would not allow the variable to be used any further. This is useful if you want to immediately free some resource without having to wait for the enclosing scope to exit, and it'll help to avoid any use-after-free shenanigans. E.g.:

let f = Foo::new();

// do some stuff with f

drop f;

// now f's resources have been freed and f itself can no longer be used

// do some other stuff

Both of these scenarios could be handled by custom methods/functions, but that requires some extra manually-defined infrastructure and gets a little bit clunky when you're dealing with generic types. E.g.:

struct Foo<T> {
    forgotten: bool;
    x: T*;
}

impl Foo<T> {
    fn new() -> Foo<T> {
        return Foo<T> {
            forgotten: false,
            x: acquire_x()
        };
    }

    // Prevent drop method from freeing resource.
    fn forget(self) {
        self.forgotten = true;
    }

    fn drop(self) {
        if !self.forgotten {
            release_x(self.x);
        }
    }
}

// Move variable and immediately drop it.
// Being a generic function, you have to type out the typename of the function arg for each call.
fn drop<T>(v: T) {
    v.drop();
}

Having dedicated operators for forget and drop that work on all Drop types without having to define any extra struct fields, methods, or functions would be a significant ergonomic improvement.

Thoughts on this?

[borup3]

I read this as two separate suggestions.

First one is to have a shorthand syntax for drop() and forget() whereby you replace s.drop() and s.forget() with drop s; and forget s;. For this first one, I'm not sure there's an improvement over just calling drop() and forget()? Adding a single-use additional syntax to replace a normal function call adds another thing you have to know about the language.

The second is having Zen C automatically make the implementations of drop(self) and forget(self) idempotent. Would this not force the size of any struct to increase which implements the Drop trait? On top of the hidden knowledge of this being handled for you automatically, I don't think I like it much. I can see users being skeptical of this, or not knowing about it, and implementing it themselves anyway using a struct member like forgotten in your example.

[davidscholberg]

The operators I'm proposing would not change the size or composition of any struct, nor would they add any methods to any type, either explicitly or implicitly. In order to implement this functionality manually (i.e. without language support), you would have to potentially add struct fields and manually define functions and methods. Part of the benefit of this being a language feature is to avoid all of that.

Also, making it so that a variable can no longer be used can't be accomplished by a method call alone (without explicit support from the language); the variable has to be moved, and a function call is currently the best way to do that. However, such a function call would have to be generic (unless you only want it to support one type), and therefore require you to type out the typename of the argument for each call. The drop operator would make this much more ergonomic (similar to how specifying types in a let statement is optional).

The Zen C compiler already has the necessary type info to accomplish all of this functionality without implicitly altering any structs nor implicitly adding any methods, nor requiring types to explicitly support it (beyond implementing the Drop trait in the simplest way possible).

[borup3]

Ok, I understand better.

Could this also be solved also by marking the variable f as moved if you call f.drop()? I'm not sure I see a need to marry this functionality to the invention of new operators. I still think there are two distinct suggestions here. One, improve the ergonomics of drop/forget. Two, possibly add operators for drop/forget.

[kyle-github]

In the first example, b.y must not be a Resource type?

Zen C treats types with destructors (like File, Vec, or malloc'd pointers) as Resources. To prevent double-free errors,
resources cannot be implicitly duplicated.

Move by Default: Assigning a resource variable transfers ownership. The original variable becomes invalid (Moved).
Copy Types: Types without destructors may opt-in to Copy behavior, making assignment a duplication.

Diagnostics & Philosophy: If you see an error "Use of moved value", the compiler is telling you: "This type owns a resource (like memory or a handle) and blindly copying it is unsafe."

So this only applies to non-resource types? What if b.y is a reference? What if it is an integer?

[davidscholberg]

Could this also be solved also by marking the variable f as moved if you call f.drop()? I'm not sure I see a need to marry this functionality to the invention of new operators. I still think there are two distinct suggestions here. One, improve the ergonomics of drop/forget. Two, possibly add operators for drop/forget.

I'd strongly advocate for not making special rules for specific methods since that would break the very reasonable assumption that all method calls are semantically equivalent. By using operators for this, it's immediately apparent in the code that something semantically different is happening than a mere method or function call.

[davidscholberg]

In the first example, b.y must not be a Resource type?

Bar is a resource type that manages the contents of y (i.e. Bar implements the Drop trait, and its drop method releases whatever resource y points to). Same story for Foo and its field x.

So this only applies to non-resource types?

These operators would apply to all types that implement the Drop trait.

[BAGR]

I don't like it. It's not consistent with other mem operations like clone and copy. Copy is a marker trait, so we should add the Forget marker trait. Drop and Clone are built-in traits and documentation states that they are for explicit definition of what must happen, but Clone can already be @derived. We should implement @derive for Drop and Forget.

[davidscholberg]

In order to solve this problem solely with method calls, the language would have to be changed to add special handling for the drop and forget methods that disallows the further use of the associated variable in its scope, and once again I will strongly advocate against violating the assumption that all method calls are semantically equivalent. Operations that are semantically different should ideally have their own semantics, particularly for a language like Zen C that prioritizes ergonomics.

[kyle-github]

In the first example, b.y must not be a Resource type?

Bar is a resource type that manages the contents of y (i.e. Bar implements the Drop trait, and its drop method releases whatever resource y points to). Same story for Foo and its field x.

So this only applies to non-resource types?

These operators would apply to all types that implement the Drop trait.

I quoted the README for Zen-C. The point was that anything that is considered a Resource is automatically subject to move semantics. So why do we need the move operator? (Cue Sade's "Smooth Operator") I am trying to understand when it would apply. From what I understand of the README, f.x = b.y would automatically move y to x thus leaving y unusable. If b.y is not a Resource, then it is not a pointer/reference so it is a value like an integer and can be copied without problems. It is certainly possibly that I am misunderstanding both the README and the proposal.

Personally I think this confusion on my part is largely due to what looks like the same pointer vs. value issue with Java. "Objects" are pointers and thus when passed can be modified by the callee. Think Integer vs. int. I would strongly prefer that Zen-C not go down this path. C# managed to mostly side step it but now is having to patch up the whole issue with value-based structs etc.

[davidscholberg]

The readme should do a better job of explaining Zen C's implementation of RAII, but here's a more concrete example where forget would be handy, and hopefully it illustrates Zen C's move semantics better:

struct Foo {
    n: int*;
}

impl Foo {
    fn new(n: int) -> Foo {
        let f = Foo { n: malloc(sizeof(int)) };
        *f.n = n;
        return f;
    }
}

impl Drop for Foo {
    fn drop(self) {
        if (self.n) {
            println "dropping foo: {*self.n}";
            free(self.n);
        }
    }
}

struct Bar {
    n: int*;
}

impl Bar {
    fn new(n: int) -> Bar {
        let b = Bar { n: malloc(sizeof(int)) };
        *b.n = n;
        return b;
    }
}

impl Drop for Bar {
    fn drop(self) {
        if (self.n) {
            println "dropping bar: {*(self.n)}";
            free(self.n);
        }
    }
}

fn main() {
    let f = Foo::new(1);
    "{*f.n}";

    let b = Bar { n: NULL };

    // This is not a move because the `n` fields are not resource types.
    b.n = f.n;

    // At this point, both f and b own the resource, so extra action is needed
    // to prevent double free and to prevent f from being used further.

    "{*f.n}";
    "{*b.n}";
}

What makes something a resource type is whether or not it implements the Drop trait. Foo and Bar are both resource types because they implement the Drop trait in order to properly manage the heap-allocated memory pointed to by the n field. The n field itself is not is not a resource type; it is the resource managed by the resource type.

[BAGR]

I knew what you meant, but the more I think about your example, the more I think it's not a good approach. Do you have any real use cases for moving a pointer like this? If I wanted to do this, I would make my intent clear by a function that consumes f.

fn extractNfromFoo(f: Foo) -> int* {
	let n = f.n;
	f.n = NULL;
	return n;
}

fn main() {
    let f = Foo::new(1);
    "{*f.n}";

    let b = Bar { n: NULL };

    // This is not a move because the `n` fields are not resource types.
    b.n = extractNfromFoo(f);

    // At this point, both f and b own the resource, so extra action is needed
    // to prevent double free and to prevent f from being used further.

    "{*f.n}";
    "{*b.n}";
}

BUT, having this as a function feels a little bit ugly, so I think that it should be possible to write it as a method that explicitly asks for moving self (which would be simple self without & in Rust, but we already use it for refs):

impl Foo {
    fn new(n: int) -> Foo {
        let f = Foo { n: malloc(sizeof(int)) };
        *f.n = n;
        return f;
    }
        // notice the '!'
	fn extractN!(self) -> int* {
		let n = self.n;
		self.n = NULL;
		return n;
	}
}

This way it will be visible to a reader that the instance gets consumed by this method.

(I also found out that string interpolation doesn't throw an error if you do *f.n after extractNfromFoo, but let n = *f.n does)

[borup3]

I agree with the above. But does the notion of forget() not already cover this well enough if you just return the forgotten value? We already have forget(self). I don't think forget(self) -> T is a big mental leap to declare that the "Caller now owns the value that's forgotten".

If you're using pointers directly, you are inherently opting into an unsafe world and that should be allowed in my opinion. I like being able to point the gun at my own foot sometimes, otherwise Rust solves my problem.

C++ solves this explicitly with std::move and implicitly when the compiler decides it has no side effects (e.g. from an rvalue, or temporary object) with the move constructor and operator.

impl Foo {
    fn forget(self) -> int* {
        let tmp = .n;
        .n = NULL;
        return tmp;
    }
}

fn main() {
    let f = Foo { n: malloc(sizeof(int)) };
    *f.n = 1;
    let b = Bar { n: NULL };

    // Intentionally take pointer n from f
    b.n = f.forget();

    printf("%p\n", f.n);
    printf("%p\n", b.n);
}

Maybe Zen C should adopt forget(self) as a first-class pattern that marks the variable as "moved" and not able to be used after invocation?