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

[zygoloid]

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]

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

[geoffromer]

@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]

Hii , please assign this to me I know about it

[clavin]

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.