Destructor syntax #5017
Destructor syntax #5017
Conversation
a2b707f to
7be4a5f
Compare
f78897a to
ef0f225
Compare
ef0f225 to
0db7620
Compare
proposals/p5017.md
Outdated
|
|
||
| Note that non-keyword names were considered as part of proposal | ||
| [#1154: Destructors](https://github.com/carbon-language/carbon-lang/pull/1154), | ||
| and |
| In particular, we are discussing destruction as possibly similar to copy and | ||
| move syntax, and trying to create a consistency between the functions. | ||
|
|
||
| ## Proposal |
There was a problem hiding this comment.
I heard the leads say they would like an explicit syntax to say that the destructor is trivial. How would that work?
There was a problem hiding this comment.
According to what leads approved in #1154:
Types satisfy the
[`TrivialDestructor`](/docs/design/generics/details.md#destructor-constraints)
type-of-type if:
- the class declaration does not define a destructor or the class defines the
destructor with an empty body `{ }`,
- all data members implement `TrivialDestructor`, and
- all base classes implement `TrivialDestructor`.
For example, a [struct type](#struct-types) implements `TrivialDestructor` if
all its members do.
`TrivialDestructor` implies that their destructor does nothing, which may be
used to generate optimized specializations.
This proposal is not suggesting to change that at this time.
There was a problem hiding this comment.
Note too, per minutes at https://docs.google.com/document/d/1Iut5f2TQBrtBNIduF4vJYOKfw7MbS8xH_J01_Q4e6Rk/edit?resourcekey=0-mc_vh5UzrzXfU4kO-3tOjA&tab=t.0, I believe the discussion about trivial destructors was constrained to the discussion about how destructors work behind the scenes -- which in this proposal, is the desugaring "future work".
There was a problem hiding this comment.
FWIW, my memory is that we did discuss wanting some explicit way to mark trivial cases, essentially forcing an error if it is mistaken.
I don't think that desire was especially connected to the desire for the semantics of these to map trivially into some set of impls of interfaces -- I think these are largely orthogonal.
Not sure why the minutes missed that or wore confusing here...
That said, this all still seems like future work. I've made a suggestion below to maybe document this in the future work without needing to dig into it further.
Syntax is proposed in #5017, but has already been discussed with leads. Semantics is left as a TODO. --------- Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
| In particular, we are discussing destruction as possibly similar to copy and | ||
| move syntax, and trying to create a consistency between the functions. | ||
|
|
||
| ## Proposal |
There was a problem hiding this comment.
FWIW, my memory is that we did discuss wanting some explicit way to mark trivial cases, essentially forcing an error if it is mistaken.
I don't think that desire was especially connected to the desire for the semantics of these to map trivially into some set of impls of interfaces -- I think these are largely orthogonal.
Not sure why the minutes missed that or wore confusing here...
That said, this all still seems like future work. I've made a suggestion below to maybe document this in the future work without needing to dig into it further.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
|
Minor note, committed a small typo fix where a sentence from the prior paragraph was repeated. |
|
Also added back-references to classes.md, seemed better to do that here than a separate PR. Going to give some time in case someone wants to comment on these final cleanups. |
Fix destructor syntax ambiguity by switching to
fn destroymirroring standard function syntax. This is a purely syntactic change, maintaining destructor semantics.This comes from leads question #4999