How should modifiers for keyword operators be spelled?

[zygoloid]

Summary of issue:

#5913 introduces a keyword operator for an unsafe conversion, and suggests spelling it as unsafe as (two keywords in sequence). When #845 considered the same question, the suggestion was instead to spell this kind of keyword-with-modifier as a single keyword, such as unsafe_as or assume_as or try_as.

Which approach do we prefer?

Details:

The simplest options here seem to be either:

• Always use compound keywords: unsafe_as, try_as. This is simple and uninventive, and seems like the most conventional option. However, it's inflexible: what if we need an unsafe_try_as?
• Always use modifier keywords: unsafe as, try as. This offers more flexibility, and is consistent with our approach to modifier keywords on declaration introducers. But it's somewhat novel and potentially surprising. There is prior art in Python's not in operator.

A third option to consider would be to say that it's unsafe that's special, not operator modifiers, and that we want a single unsafe keyword that's used consistently in all unsafe constructs for easy auditability. For example, we could eventually have: as, unsafe as, try_as, unsafe try_as.

Any other information that you want to share?

Multi-keyword operators would presumably allow arbitrary amounts of whitespace, including line breaks and line comments between the operators, which may be surprising but could be mitigated by making the formatter always keep them together on a line. There's also a possibility that multi-keyword operators may be harder to read, due to the possibility of misparsing them as (x unsafe) as y, but I'm not aware of that being a problem for python's a not in b, which could be misinterpreted as the valid-but-meaningless as a in not b.

[chandlerc]

A third option to consider would be to say that it's unsafe that's special, not operator modifiers, and that we want a single unsafe keyword that's used consistently in all unsafe constructs for easy auditability.

FWIW, #5914 specifically proposes that we want an unsafe keyword like this.

But that doesn't require us to follow the third option here, it might simple be motivation for the second option (which is my mild preference at the moment).

[CJ-Johnson]

I think being able to say "show me all the unsafe code" is very valuable, so having a canonical keyword for such would be great! I also think being able to say "show me all the cast code" is valuable (though less so) and thus having a canonical cast keyword seems like a feature. And for the case where you want to find the unsafe casts specifically? Well just look for the keywords side by side :)

[chandlerc]

After some discussion, the leads ended up comfortable with separate modifier keywords such as unsafe as and try as. But specifically in the case where they are meaningfully modifiers.

• There is some hierarchy or other collection of operations with a core keyword, and modifiers select specific variations.
• The keywords are reasonable to exist as keywords in isolation and don't change meaning in confusing ways when composed in this way.

This doesn't take any stance on whether we should or should not have keywords with _s when the words involved are not reasonable to model in this way, either not really modifying a common operation, or not reasonable as independent keywords.

The rationale is that the modifier keyword structure helps highlight the relationship between the operations, and facilitates things like auditing based on either component of the combination. We ended up quite comfortable with the modifier syntax, if a bit surprised at that level of comfort. =]

If specific problems arise with this approach, we can also revisit this.