Idea : Explicit And More Flexible Lifetime Annotation And Thread's At Exit Hook

[mathstuf]

@fuji-184

let mut val = String::new() until MyLifetime3;
let handle = thread::spawn(|| {
    val.push("Hello");
});

// the heap is automatically dropped after the thread finish
handle.at_exit(|| {
    close MyLifetime3;
});

handle.join();

How is anyone to know that MyLifetime3 is to be moved into the at_exit closure and not kept in the calling scope (yet is still associated with it)? Why is it not moved into the spawn closure? You really need more structuring here. How is any kind of checker to know that spawn and at_exit have this "at_exit can end lifetimes for things in spawn because…it is required to be called after spawn is done with its caller" property?

@fuji-184

I don't have knowledge at that level, so it will be the team and other more knowledgeable to find way how to achieve this. I share the end goal/idea

I'll quote myself here:

@mathstuf

Here, there are questions about the implications of your proposal. Now, if you want to say "do what you need, I just want my feature" and the implications that come from it and the solutions that actually end up happening make what you actually wanted impossible, you're going to be disappointed and Rust is going to have more complexity with little compensation beyond "somebody asked for something and we did it".

That's why proposals of any significant complexity (of which this certainly is) should really be done in RFC form (even if labeled as a pre- or pre-pre- stage). Its structure helps to get yourself to ask these kinds of questions before it gets wallowed in the details of how things actually end up having to work when put into instructions for a machine to actually perform.