Unreserving the word "override" as a reserved keyword

Currently override is a reserved keyword, which I found out when trying to give that name to a fn. To the best of my knowledge, no actual functionality is linked to override. So given that, what would it take to get it unreserved?

FWIW: I'm aware that it's possible to name the fn r#override but I consider that unergonomic enough to not be worth it. Currently I've settled on with_override but the word override when used as a verb is more appropriate.

1 Like

In the past it was done via an RFC, which includes some justification why override was not removed.

Ok, the main reasons seem to be specialization and delegation.

That is too bad, override would have been useful as an identifier.

To me override is more meaningful as a verb, whereas an identifier is a noun. I perfer the status quo, with those words reserved for potential future use with specialization and delegation.

I was talking about a fn identifier. Generally those are verbs.

2 Likes

Could it not be a contextually reserved keyword instead?

:+1:

I would be happy to see it unreserved for use as an identifier. I'm slightly more hesitant to unreserve it in the specific context of "things that can appear at the start of one item within a trait definition".

1 Like

In general I feel that most keywords should be contextual as much as union is, but I can understand this might be a tough sell to the lang team. :innocent:

3 Likes

My recollection is that union works well because it's on an item, but we ended up making dyn a full keyword (despite the original contextual plan) because in more complicated positions the ambiguity was more awkward.

If this would always be used as override fn, then it'd probably be fine as contextual. (But I'm no grammar expert, so don't bank on that.)

If it's ever used for specialization, I don't consider override trait Foo { } unthinkable, but that's is completely dependent on the design of that feature.