You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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] {}.
The text was updated successfully, but these errors were encountered:
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.
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
Our syntax for an out-of-line definition of a destructor looks like this:
In all other declaration forms, when we have
introducer_keyword identifier
, theidentifier
is the name of the entity being declared. However, in this case, the nameC
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:
fn <special>[self: Self]();
andfn Class.<special>[self: Self]() {}
. Choices for the "special name" include:destructor
, where we keepdestructor
as a keyword:fn destructor[self: Self]();
orfn Class.destructor[self: Self]() {}
. This somewhat parallels what we do with thebase
keyword as a pseudo-member-name.~
:fn ~[self: Self]()
orfn Class.~[self: Self]() {}
. This mirrors the current idea of using~
as an operator to express destructive ownership transfer.~Self
:fn ~Self[self: Self]()
orfn Class.~Self[self: Self]() {}
. This would be very C++-like.()
.for
keyword afterdestructor
:destructor for C [self: Self] {}
.The text was updated successfully, but these errors were encountered: