Terminology for internal and external implementations

[josh11b]

The decision #995 retires the keyword external to mark external implementations, and instead uses extend to mark internal implementations. Should we change the terminology in the documentation to match? If so, what terminology should we use instead?

[chandlerc]

I think we should change to match.

"extended implementations" and "implementations" would be my initial suggestions.

There is a question of how important it is to have a dedicated or positive term for the non-extended case?

[josh11b]

The non-extended case has different rules, for example:

• external implementations may be defined in different libraries
• blanket implementations must be external

[chandlerc]

The non-extended case has different rules.

Yes, but that alone doesn't make it clear to me how important it is to have a dedicated term? I'm guessing you're trying to say that it is somewhat important, but I'm still not sure where that leaves things.

I also don't have any ideas for what the term should be here, but if you or others do, then maybe its a moot point.

Unrelated minor question:

• blanket implementations must be external

Isn't this just conditional blanket implementations? I may be getting confused though.

[josh11b]

Isn't this just conditional blanket implementations? I may be getting confused though.

We don't say "conditional blanket implementations" since it is redundant, all blanket implementations are of the form "for all types satisfying a criteria..."

[mconst]

I'd avoid introducing a separate term for non-extended impls. I think your examples both become clearer if we phrase them in terms of where you're allowed to write extend:

• blanket implementations must be external

I'd say "you can't extend a blanket impl".

• external implementations may be defined in different libraries

This one feels kind of obvious given #995, so we might not need to state it at all. But if it comes up, I'd say something like "you can't use extend outside the class definition, but you can always impl your own interface for the class and then call those methods using qualified member access".

In general, to get the maxmium benefit from #995, I think we should try to treat impl and extend as separate concepts as much as possible. If we run into a lot of cases where that doesn't work, then that would be a sign to maybe revisit #995, but these examples seem like they fit the model nicely.

[josh11b]

In general, to get the maxmium benefit from #995, I think we should try to treat impl and extend as separate concepts as much as possible. If we run into a lot of cases where that doesn't work, then that would be a sign to maybe revisit #995, but these examples seem like they fit the model nicely.

I find this argument compelling.

[josh11b]

I'm in an airport with two leads, and we agree with the resolution and rationale from #2770 (comment)