Skip to content
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

out-of-line destructor syntax seems inconsistent with other declaration forms #2567

Open
zygoloid opened this issue Jan 30, 2023 · 4 comments
Labels
long term Issues expected to take over 90 days to resolve.

Comments

@zygoloid
Copy link
Contributor

zygoloid commented Jan 30, 2023

Our syntax for an out-of-line definition of a destructor looks like this:

class C {
  destructor [self: Self];
}
destructor C [self: Self] {
}

In all other declaration forms, when we have introducer_keyword identifier, the identifier is the name of the entity being declared. However, in this case, the name C isn't being declared; rather, its destructor is being declared. This seems inconsistent.

#1154 doesn't list any considered syntactic alternatives for its chosen form of destructor (as a special function-like member). Here are a few we should explicitly consider:

  • Using regular function syntax with a special name, instead of a special introducer: fn <special>[self: Self](); and fn Class.<special>[self: Self]() {}. Choices for the "special name" include:
    • destructor, where we keep destructor as a keyword: fn destructor[self: Self](); or fn Class.destructor[self: Self]() {}. This somewhat parallels what we do with the base keyword as a pseudo-member-name.
    • ~: fn ~[self: Self]() or fn Class.~[self: Self]() {}. This mirrors the current idea of using ~ as an operator to express destructive ownership transfer.
    • ~Self: fn ~Self[self: Self]() or fn Class.~Self[self: Self]() {}. This would be very C++-like.
  • As previous option, but without the ().
  • In the out-of-line case, add the for keyword after destructor: destructor for C [self: Self] {}.
@AnonymousDeveloper156
Copy link

Hi! i wanna work on this. Please assign me this task,

@geoffromer
Copy link
Contributor

@AnonymousDeveloper156 See our contributing guide:

When triaging issues, we typically won't assign issues because we want to be confident that contributors who have an issue assigned to them are planning for the amount of time it will take, which requires familiarity. Contributors with write access are expected to have that familiarity and may assign issues to themselves.

@ghost

This comment was marked as off-topic.

@github-actions github-actions bot added the inactive Issues and PRs which have been inactive for at least 90 days. label Jul 17, 2023
@chandlerc chandlerc added long term Issues expected to take over 90 days to resolve. and removed inactive Issues and PRs which have been inactive for at least 90 days. labels Aug 6, 2023
@carbon-language carbon-language deleted a comment from github-actions bot Aug 6, 2023
@clavin
Copy link
Contributor

clavin commented Feb 26, 2024

I started a discussion in Discord about potential names for the fn <special>[self: Self]() case. We came up with a couple of options to consider:

  • delete
  • destroy
  • destruct

One potential advantage for all three is that they are verbs, which matches the common naming of a function like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
long term Issues expected to take over 90 days to resolve.
Projects
None yet
Development

No branches or pull requests

5 participants