-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: support explicit delete in golang #46429
Comments
Dup of #43582 (and possibly others). We aren't going to do this. Sorry. |
hello, i think support explicit delete exceed the need. ok, after i say these words, i found already it is very different from golang |
The compiler already does stack allocate objects that can be proven not to escape. If the compiler cannot prove they do not escape, then adding an override would create a memory safety issue. The better path would be to fix the compiler, or use the //go:noescape annotation. |
Especially now many people use tinygo to run on the MCU (singlechip). When the memory is used up, it will be released immediately, which is a little important. Just like today's cars, they generally have automatic and manual gears, which can also be called automated manual transmission (AMT), which can be selected according to the needs of users. Improve user experience. ??? |
if we know in advance that x's lifetime will finish when outer end. can we mark delete x. and the compiler can safely alloc x on stack.
most times, we know which objects could safely be deallocated just like in lang without gc, could we delete them immediately to relief gc pressure ?
proposal:
support markDelete in golang to tell compiler to alloc on stack or immediately dealloc object.
add check code in markDelete to detect false delete in runtime just like how raceenable works.
The text was updated successfully, but these errors were encountered: