carbon-lang
carbon-lang copied to clipboard
carbon-language
Feature destructor
I hope it is useful...!
~~For the last step, I need help... How to change the fuzzer that it create destructors not methods?~~
For the last step, I need help... How to change the fuzzer that it create destructors not methods?
Generally the changes to the AST will need to be mirrored to carbon.proto. See https://github.com/carbon-language/carbon-lang/blob/trunk/explorer/fuzzing/README.md#incorporating-ast-changes-into-the-fuzzer for notes on adding features.
Note, it's not obvious to me that destructors should reuse FunctionDeclaration versus having their own type because of how distinct they are, but maybe that's best discussed with zygoloid in review. (I'll be out for the next couple weeks)
The tests are failing. Also, in all the tests, I don't see any expected output from the destructor prints: is this expected to not call destructors?
Sorry, I forgot to run update_checks
Note, it's not obvious to me that destructors should reuse FunctionDeclaration versus having their own type because of how distinct they are, but maybe that's best discussed with zygoloid in review. (I'll be out for the next couple weeks)
From my point of view, is a destructor only a method, that can't be called from user. If we add a DestructorDeclaration class, we will repeat much code from FunctionDeclaration... Also we grow up the code base in the interpreter and that only for the reason to prevent the check is_destructor.
From my point of view, is a destructor only a method, that can't be called from user.
C++ allows calling the destructor because there are cases where it is necessary to be able to do so, for example if you want to separate memory allocation and initialization by using placement new (see placement new section on https://en.cppreference.com/w/cpp/language/new).
Short explanation: The placement new operator does not allocate memory but uses pre-allocated memory instead. You can't call delete because no memory was allocated. so the destructor is never called, unless you do it yourself. This allows developers to allocate memory once and reuse it as much as they need to.
alignas(Object) unsigned char buffer[sizeof(Object)]; // memory is allocated and freed when buffer goes out of scope
Object* object = new(buffer) Object; // object is initialized at memory location of buffer
object->~Object(); // object destructor needs to be called directly.
Most C++ developers never need to use this, but it is a powerful feature that can be very useful if you are developing for devices with limited memory capabilities for example (allocating memory is slow or not always possible). I think Carbon will need a similar feature if it wants to be a viable option for that specific segment of C++ development.
I am not saying that destructors need to be callable by the user, definitely not. I don't think the C++ syntax for this is good, I just want to want to raise awareness of a useful but not well known feature of C++.
From my point of view, is a destructor only a method, that can't be called from user.
C++ allows calling the destructor because there are cases where it is necessary to be able to do so, for example if you want to separate memory allocation and initialization by using placement new (see placement new section on https://en.cppreference.com/w/cpp/language/new).
Short explanation: The placement new operator does not allocate memory but uses pre-allocated memory instead. You can't call delete because no memory was allocated. so the destructor is never called, unless you do it yourself. This allows developers to allocate memory once and reuse it as much as they need to.
alignas(Object) unsigned char buffer[sizeof(Object)]; // memory is allocated and freed when buffer goes out of scope Object* object = new(buffer) Object; // object is initialized at memory location of buffer object->~Object(); // object destructor needs to be called directly.Most C++ developers never need to use this, but it is a powerful feature that can be very useful if you are developing for devices with limited memory capabilities for example (allocating memory is slow or not always possible). I think Carbon will need a similar feature if it wants to be a viable option for that specific segment of C++ development.
I am not saying that destructors need to be callable by the user, definitely not. I don't think the C++ syntax for this is good, I just want to want to raise awareness of a useful but not well known feature of C++.
Also this is not an argument to develop a DestructorType...! On the contrary, it is a reason to handle a destructor more like a normal method, or not ?
Also this is not an argument to develop a DestructorType...! On the contrary, it is a reason to handle a destructor more like a normal method, or not ?
It depends on if and how Carbon would implement a placement new. C++ doesn't have a placement delete (trivial to implement yourself though), but Carbon might have one, in which case the destructor would called by the placement delete and there would be no need to call a destructor directly.
I wasn't really offering an opinion on how to implement destructors in Carbon, just wanted to offer a reason why C++ allows calling destructors. Which lead me to wanting to suggest Carbon could benefit from having its own placement new.
Thank you for the CallableDeclaration changes! I believe they pretty much match what @geoffromer and I were thinking about.
Just to note, I think this PR is reaching a good shape to merge. It may be good to start adding TODO comments on remaining issues, and then we can work incrementally there.
I think @geoffromer would like documentation on the functions you're adding to RuntimeScope in particular though, in order to better understand what they're doing.