On Tue Oct 13, 2026 at 5:26 PM JST, Eliot Courtney wrote:
>>> +///
>>> +/// A schema that doesn't need to borrow data from the stream can
>>> implement this for all `'data`
>>> +/// lifetimes, avoiding having to carry the lifetime parameter. A schema
>>> that borrows from the
>>> +/// stream directly should implements it for its own lifetime only.
>>> +pub(crate) trait Visit<'data> {
>>
>> Should this be named `Visitor` instead of `Visit`? Trait names should be
>> nouns rather than verbs, and this would make the `Decoder::visit`
>> method's prototype read more clearly imho. If you intended to use
>> `Visit` as a noun, I don't think that works either since the `visit`
>> method is potentially called many times (so it is not a single visit).
>
> According to [1], traits should preferably be named as verbs, and it in
> particular calls out the case where there's one fn in the trait:
>
> ```
> This RFC proposes to amend the convention to further say: if there
> is a single method that is the dominant functionality of the trait,
> consider using the same name for the trait itself.
> ```
>
> That said in the kernel there are more noun/noun phrase traits. So no
> worries to rename it to Visitor. But I wouldn't say trait names should
> be nouns as a rule, it seems that the prescriptive answer is to prefer
> the opposite.
Let's follow the Rust rule then - `Visit` it is. My issue with it
probably came from the fact that "visit" can be both a verb and a noun,
and the doccomment calls it "A visitor". But if we rewrite the doccomment
to use "visit" as a verb instead, like "Trait for types that visit ..."
the intent should be clearer.
