# Spelling bikeshed: "implementor" or "implementer"?

**URL:** <https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926>\
**Category:** documentation\
**Created:** [July 2, 2022, 7:09pm UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926 "2022-07-02T19:09:43Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\
**Post date:** [July 2, 2022, 7:09pm UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/1 "2022-07-02T19:09:43Z")

</div>

Currently ([6a10920](https://github.com/rust-lang/rust/commit/6a1092056441652fe5fe5c5b422644951e6b99ce)), "implementer" is used 49 times in rust-lang/rust, compared to "implementor" which is used 274 times.

[According to Google Ngrams](https://books.google.com/ngrams/graph?content=implementor%2Cimplementer&year_start=1900&corpus=26&smoothing=3), "implementer" is the more used spelling my a wide margin, both in American English (by a wider, accelerating margin ~ 20×) and in British English (by a smaller margin ~ 10×).

[dictionary.com lists](https://www.dictionary.com/browse/implement) both forms with -er first, as does [Merriam-Webster](https://www.merriam-webster.com/dictionary/implement).

Cambridge Dictionary [lists -er](https://dictionary.cambridge.org/us/dictionary/english/implementer) but [not -or](https://dictionary.cambridge.org/us/spellcheck/english/?q=implementor). The Firefox en-US spellcheck dictionary accepts implementer but not implementor.

* * *

Obviously the choice is fairly arbitrary; by [any reasonable interpretation](https://english.stackexchange.com/a/358111) both forms are still accepted. I do think it makes sense to standardize the existing uses in rust-lang/rust onto a single spelling.

"implementor" could be chosen due to currently being the more used spelling in the repo.  
"implementer" could be chosen due to being used more frequently, especially in AmEng which the rust project tends to prefer.

What do you think?

_Poll ([view on site](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/1))_

---

<div class="post-metadata">

**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\
**Post date:** [July 2, 2022, 7:33pm UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/2 "2022-07-02T19:33:28Z")

</div>

Given Ngrams alone, -er seems to be the most reasonable choice.

> [@CAD97](#):
>
> [dictionary.com lists](https://www.dictionary.com/browse/implement) both forms with -er first, as does [Merriam-Webster](https://www.merriam-webster.com/dictionary/implement).

Neither is listed as "less common", "uncommon", or similar language, so they're actually co-equals (and likely just listed in alphabetical order).

* * *

Overall I'd love to have someone go through and fix typos and standardize to American English (which is what is officially preferred last I checked).

---

<div class="post-metadata">

**Author:** ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh)\
**Post date:** [July 2, 2022, 9:21pm UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/3 "2022-07-02T21:21:52Z")

</div>

I have the impression that `implementor` is a hacker-ism; there are a few other words for which `-or` is more common in technical writing even though `-er` is more common in general English.

No objections to changing to the more common usage in this case.

---

<div class="post-metadata">

**Author:** ![burntsushi](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/burntsushi/32/279_2.png) [@burntsushi](https://internals.rust-lang.org/u/burntsushi)\
**Post date:** [July 2, 2022, 10:10pm UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/4 "2022-07-02T22:10:56Z")

</div>

Why do we have to, or why should we, pick one to use at the expense of the other?

Picking one and changing all existing usages to it strikes me as adding noise to the commit logs. Although, I admit that the numbers here are small enough that the downside here is probably close to nil. So doing that seems fine... But what doesn't seem that great is how we maintain that standard. Are we going to have automated tooling to check for banned usages? If so, that will at least not waste reviewer time and probably has a high likelihood of maintaining the standard. Maybe that would be fine? But without automated tooling checking for banned usages, this strikes me as more trouble than it's worth.

Personally, I don't think "consistency" is a good reason in this particular example. I grant it is a reason, but one with probably very small upside. The downside is that everyone writing docs needs to be aware of this rule.

If it's one rule on one particularly not too common word, then in practice, it probably won't waste too much time. But if this is the first step in a long list of banned words in the name of consistency, then I think I would be opposed to that.

Apologies if I took this in a different direction than what was intended here, but I'm just personally very skeptical of these sorts of rules.

EDIT: to be clear, I am okay with having official preferences. And maybe that's all that's being asked for here. In which case, I would say to just ignore this comment. 🙂 But with the caveat that those preferences don't get elevated to burning time during PR reviews.

---

<div class="post-metadata">

**Author:** ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh)\
**Post date:** [July 2, 2022, 11:02pm UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/5 "2022-07-02T23:02:41Z")

</div>

Clarifying: I think this is a matter for style guides and occasional cleanups, not CI and tidy tools.

---

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [July 2, 2022, 11:08pm UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/6 "2022-07-02T23:08:47Z")

</div>

I have to agree with burntsushi here.

Having a rule for these seems worth it for a particular _book_, but for the docs overall seems like more trouble than it's worth.

---

<div class="post-metadata">

**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\
**Post date:** [July 3, 2022, 12:09am UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/7 "2022-07-03T00:09:51Z")

</div>

> [@burntsushi](#):
>
> Why do we have to, or why should we, pick one to use at the expense of the other?

Mostly: this is a bit of a curiosity from me running into saying "implementers of a trait" immediately followed by a link to rustdoc's "Implementors" section. I'm very much a descriptivist rather than a prescriptivist, but I also definitely find examining grammatical subtleties interesting.

> [@scottmcm](#):
>
> Having a rule for these seems worth it for a particular _book_, but for the docs overall seems like more trouble than it's worth.

For internal documentation / comments / etc, I fully agree that it doesn't really matter. What matters about language is that the meaning is communicated with minimal loss of precision, and if that is met, the rest doesn't really matter\[1\].

But that said, _the API documentation_ as a unit is (ideally) a cohesive whole the same way any book is. Consistent use of language helps in precision; inconsistent use of spelling may imply a different meaning between the spellings.

Rustdoc's "Implementors" section existing on every trait page probably means it's better to normalize to that.

* * *

I think I have my own little bit of grammatical differentiation between the spellings. While it is a loose association, I think I use/differentiate _both_ spellings with slightly different definitions w.r.t. _time_:

- Implementer: One who _has_ implemented
- Implementor: One who _provides_ implementation

When spellcheck is yelling at me, I end up correcting to _implementer_ consistently. When using both in close proximity to each other, I'll normalize to one or the other. But I think in a vacuum, I'd say that _myrrlyn is the implementer of bitvec_ but _myrrlyn is the implementor for bitvec_. There's grammatical subtlety there that I (as an armchair linguist) am not capable of pinpointing exactly. (And it's the kind of thing where observing the behavior influences the behavior; to get a proper study you'd have to have legacy data to analyze, contextualize it to the time period, etc.)

* * *

1. A really fun paraphrase along those lines: the english spelling reform comes when we stop correcting peoples' spelling.

---

<div class="post-metadata">

**Author:** ![carols10cents](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/carols10cents/32/98_2.png) [@carols10cents](https://internals.rust-lang.org/u/carols10cents)\
**Post date:** [July 3, 2022, 2:18am UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/8 "2022-07-03T02:18:12Z")

</div>

FWIW [I've standardized TRPL on "implementor" precisely to match the "Implementors" section in the API docs](https://github.com/rust-lang/book/pull/913/commits/40910f557c328858f230123d1234c1cb3029dda3). I have spellcheck in the book's CI and it has caught me spelling it the other way occasionally. Spellchecking code would be... tricky, though.

---

<div class="post-metadata">

**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\
**Post date:** [July 3, 2022, 2:52am UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/9 "2022-07-03T02:52:26Z")

</div>

I haven't checked how it handles this specific case, but there is a crate that fors spell checking. It's meant for CI, so it minimizes false positives.

> **[GitHub - crate-ci/typos: Source code spell checker](https://github.com/crate-ci/typos)**
>
> Source code spell checker. Contribute to crate-ci/typos development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [July 3, 2022, 7:30am UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/10 "2022-07-03T07:30:54Z")

</div>

> [@CAD97](#):
>
> Rustdoc's "Implementors" section existing on every trait page

That's a good point.

I wonder if it'd make sense to just say "Types implementing this trait" for that header to avoid the question, and the potential -er/-or distinction.

---

<div class="post-metadata">

**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\
**Post date:** [July 3, 2022, 9:38am UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/11 "2022-07-03T09:38:38Z")

</div>

Arguably there’s currently an inconsistency between the names of the sections

- Implementations on Foreign Types
- Implementors

anyway? I mean, not a bad one, but these sections _could_ be more similarly named either as

- Foreign Type Implementors
- Implementors

or as

- Implementations on Foreign Types
- Implementations

* * *

Except that “Implementations” is currently also used for _methods (and associated functions) on the trait object type_, see e.g. [Any in std::any - Rust](https://doc.rust-lang.org/std/any/trait.Any.html#implementations).

I’m now seeing an inconsistency between the use of “Implementations” on the main page vs. “Methods” in the sidebar _for the same section_. That’s weird… It’s even weirder for _traits_, because they then have

- Required Methods
- Provided Methods
- Methods

in the side-bar, where the first two are about _trait methods (and associated function)_ and the last one is about _methods (and associated functions) on the trait object type_.

* * *

TL;DR, I think there’s room for improvement, and possibly the best solution would also drop the word “Implementors” anyway.

---

<div class="post-metadata">

**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\
**Post date:** [July 3, 2022, 10:02am UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/12 "2022-07-03T10:02:25Z")

</div>

_sorry, this is probably getting kind-of offtopic; we can move to a different thread, if anyone wants to discuss this further_…

Maybe just stick with the (slight) abuse of “Methods” for methods+associated-function, then “Implementations” is only used for “Trait Implementations” on documentation pages for types, and for “Implementations on …” on documentation pages for types.

The sections could then be renamed (and re-arranged) e.g. as

- Implementations on Upstream Types
- Implementations on Local Types
- Blanket Implementations
- Downstream Implementations

or

- Implementations on Types in Dependencies
- Implementations on Local Types
- Blanket Implementations
- Implementations in Reverse-Dependencies

or something like that; splitting up the “Implementors” further seems useful anyways: The current category “… on Foreign Types” is confusing anyways, as it’s not clear whether the foreign types are in upstream crates, or downstream crates, and blanket implementations apply to foreign types, too, anyways!

(Under blanked implementations, I would _at least_ list impls on `Self` being a generic variable `T`, but also things like `&T` or `Box<T>` where the `Self`-type doesn’t [cover](https://doc.rust-lang.org/stable/reference/items/implementations.html#trait-implementation-coherence) the generic type variable. This categorization would also give more awareness to the fact that introducing such implementations is a breaking change, and that thinking about on such implementations when publishing a trait is important.)

* * *

Looking back at `Any`, the trait implementations for the trait object should probably get a new name, too, because “Trait Implementations” is confusing. Perhaps simply “Trait Implementations of dyn Any” (i.e. insert the name of the trait object) or “Trait Implementations of Trait Object” is better. Same for “Methods of dyn Any” instead of “Methods”, I guess.

---

<div class="post-metadata">

**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\
**Post date:** [July 4, 2022, 2:41am UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/13 "2022-07-04T02:41:04Z")

</div>

The word “implementors” is also exposed in rustdoc URLs:

[https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#implementors](https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#implementors)

We can change the visible name of the section, but we probably don’t want to change the anchor. Is there any APIs or API-like usage of “implementers”?

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [October 2, 2022, 2:41am UTC](https://internals.rust-lang.org/t/spelling-bikeshed-implementor-or-implementer/16926/14 "2022-10-02T02:41:14Z")

</div>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
