Boilerplate for building visitors, inspired by
derive-visitor.
Visitors and drivers
The basic purpose of this crate is to provide a simple derive macro that does "call a function on each field of this type". This building block can then be used for a ton of things, and I'm hoping to save people work by providing it.
In this crate, "visiting a type" is the name we give to "calling a function on each of its fields".
The Visit[Mut] and Drive[Mut] traits of this module provide the simplest interface for this:
a type that implements a Visit<A> + Visit<B> for a bunch of types is like a bundle of FnMut(&mut A), FnMut(&mut B) closures, and <T as Drive>::drive_inner(v) on a type T calls <V as Visit<FieldTy>>::visit on each field of T.
The Drive/DriveMut derive macros implement these types automatically for a type. With that
boilerplate out of the way, it becomes easy to define flexible visitors.
The output of the derive macros looks like:
As you can see, this is not recursive in any way: x.drive_inner(v) simply calls v.visit() on
each field of x; it is up to the visitor to recurse into nested structures if it wishes to do so.
Defining useful visitors
On top of the Drive/DriveMut derive macros, this crate provide more opinionated utilities to get
simple visitor architectures started.
A visitor is a type that implements Visit<T>/VisitMut<T> for a set of types T. An
implementation of Visit[Mut] typically involves doing some work then calling x.drive_inner(self)
to recurse into the type's contents. The crate provides Visit and VisitMut derive macros to make
such usage straightforward.
// recurse without custom behavior
// recurse on a polymorphic type without custom behavior
// call `self.enter_my_node` before recursing
// do nothing when visiting a string
;
/// Concatenate all the strings in this list.
This expands to:
;
// Recurse without custom behavior
// Recurse without custom behavior
// Call `self.enter_my_node` before recursing
// Do nothing on a string
The options available are:
enter(Ty): callself.enter_ty(x)before recursing withdrive_inner.exit(Ty): callself.exit_ty(x)after recursing withdrive_inner.override(Ty): callself.visit_ty(x)?, which may or may not recurse if it wishes to and can also early-return.drive(Ty): recurse withdrive_inner.skip(Ty): do nothing.Ty: alias foroverride(Ty)
Instead of Ty, one can always write for<A, B, C> Ty<A, B, C> to make a generic impl. For
enter, exit and override, one may also write other_name: Ty so that visit_other_name is
called instead of visit_ty.
Overrideable visitor architecture via traits
For more complex scenarios where one-off visitor structs would be tedious, this crate provides
a final macro: visitable_group. Given a set of types of interest, this generates a pair of
traits: a Visitable trait implemented by all these types, and a Visitor trait with default
methods that defines visitors over these types.
This is a reusable version of the one-off visitor structs we saw in the previous section: the
enter_foo/exit_foo/visit_foo methods are now trait methods, in such a way that many
visitors can be defined for that same set of types.
;
// The `ListVisitor` trait was generated by the `visitable_group` macro.
// Calling `visitor.visit(&list)` will run the visitor on the list.
The generated visitor trait has methods much like those from the Visit[Mut] derives, that can
be overridden freely. The result is:
/// Implementation detail: wrapper that implements `Visit[Mut]<T>` for `T: ListVisitable`,
/// and delegates all the visiting to our trait's `drive[_mut]`. Used in the implementation of
/// `visit_inner`
;
To illustrate, the typical visit loop would look like, given a MyVisitor: ListVisitor:
<MyVisitor as ListVisitor>::visit(v, x)// entrypoint<Node as GroupVisitable>::drive_list(x, v)// assumingx: Node<MyVisitor as ListVisitor>::visit_node(v, x)// here lives custom behavior<MyVisitor as ListVisitor>::visit_inner(v, x)// assumingvisit_nodewas not overridden<Node as Drive>::drive_inner(ListVisitorWrapper(v))- calls
<MyVisitor as ListVisitor>::visit(v, &x.field)on each field ofx, completing the loop.
The options available for the visitable_group macro are:
visitor(drive_method_name(&[mut]TraitName)[, infallible]): derive a visitor trait namedTraitName.- the presence of
mutdetermines whether theTraitNamevisitor will operate on mutable or immutable borrows. - the optional
infallibleflag enables an infallible-style interface for the visitor:, where its methodsvisit_$tyreturn()instead ofControlFlow<_>.
- the presence of
drive(Ty)andskip(Ty): behave the same as their counterparts in theVisitandVisitMutderives described above.override(Ty): generatesenter_tyandexit_tymethods that do nothing, and avisit_tymethod that callsenter_ty, recurses withself.visit_inner()?, then callsexit_ty.override_skip(Ty): similar tooverride(Ty), but the default implementation does nothing, and noenter_Tyorexit_Tymethods are generated.
Note: the visitable_group interface makes it possible to write composable
visitor wrappers that provide reusable functionality. For an example, see
[derive_generic_visitor/tests/visitable_group_wrapper.rs].