Replace keyword is with impls

[josh11b]

Use the keyword impls instead of is when writing a where constraint that a type variable needs to implement an interface or named constraint.

What was previously (provisionally) written:

fn Sort[T:! Container where .ElementType is Ordered](x: T*);

will now be written:

fn Sort[T:! Container where .ElementType impls Ordered](x: T*);

[jonmeow]

I'm trying to figure out the best way to put this:

1. What is impl short for if we were to treat it as a word? Is it the same as with "implements" for impls, or do you think of it as something longer, like "implementation of"?
2. Will newcomers to the language understand that when we have both, one is not a pluralization of the other?
3. In documentation, can we also replace "impls" where it's used to mean a plural of impl to be something else?

For example on my point 3, look for uses of "impls" in https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/generics/details.md. Regardless of the rest, I think these will also need to be cleaned up in order to reduce confusion. But I have no idea what to suggest, to my point 2.

[josh11b]

1. What is impl short for if we were to treat it as a word? Is it the same as with "implements" for impls, or do you think of it as something longer, like "implementation of"?

impl comes from Rust, where I think it is short for "implementation of," as in "implementation of Display for i32." This matches the Carbon convention where the introducer keywords correspond to nouns ("implementation", "function", "variable", "class") not verbs ("implement" or "implements").

[jonmeow]

Might also be good to rename pre-existing uses of impls in code in order to avoid confusion (maybe impl_list?)

[josh11b]

Added some text about this concern to the alternatives considered section: 5c31cb5

[jonmeow]

Added some text about this concern to the alternatives considered section: 5c31cb5

I think you might be misunderstanding my concern, because the text focuses on the expanded meaning instead of the two possible readings of "impls". This PR also does not fix existing uses of "impls" in order to resolve ambiguity.

For example:

• generics/details.md has multiple cases, such as "Parameterized impls" (particularly in the Table of Contents)
• explorer code uses "impls" in variable names.
• There are proposals such as "Generics details 7: final impls #983", linked from the bottom of details.md
• "impls" is also going to come up in spoken discussion.

My concern is that, in creating a second possible reading for "impls", it's harder to understand both code and documentation. Context is not always present: I don't think the above examples have much that can be relied on by readers to disambiguate. I think I'll find it challenging to understand the above cases; I would expect this to be particularly difficult for non-native English speakers.

But if you disagree, please at least edit the existing uses of "impls" to remove ambiguity. I believe we should avoid using "impls" when it does not mean impls. "impls" is at least an improvement for markdown, and that's why I suggest "impl_list" in explorer code where we still need a valid variable name.

[jonmeow]

My concern is specifically with the choice of impls. If you used the keyword implements instead, that would avoid the ambiguity I'm noting, but I assume it was avoided due to length. Would something like has work for you, or maybe has_impl?

Is this similar to requires from C++20?

[josh11b]

I filed a question-for-leads issue #2495 and posted a question in the #naming channel on Discord about the word to use for this keyword.

[jonmeow]

Thanks for the doc edits. :)

[josh11b]

I believe this is now ready for review.

[chandlerc]

FWIW, it would seem useful for this to be split up into maybe proposal, doc-updates, toolchain updates, and explorer updates....

Would doing that at this point create too much git hassle? Fine if so, I'll try to work through it in phases.

[josh11b]

FWIW, it would seem useful for this to be split up into maybe proposal, doc-updates, toolchain updates, and explorer updates....

Would doing that at this point create too much git hassle? Fine if so, I'll try to work through it in phases.

I've created #2707 and moved all the explorer and toochain changes into that PR.

[chandlerc]

Approving as I think the critical and controversial part has been clearly resolved on the issue. =]

The doc updates all LG. I've left two minor suggestions on the proposal. LG and feel free to land with the suggestions. Also happy to chat more if any don't make sense.