This is nicer as the current interface, as it allows the user to chain this with iterator adaptors instead of using a mutable state captured from the environment.
However, the implementation is certainly somewhat trickier. For instance, it is a bit awkward to generalize over SomeIterator<_> without higher-kinded types (which Rust 1.0 will not include). This is also mentioned under limitations in the associated types RFC rust-lang/rfcs#195. A workaround could look like this:
Now one would have to implement QueryableOwned<&'a D> for &'a T, so that T can implement DataQuery<D>. This is a bit complicated, so I am not sure whether it is worth the effort.
On the other hand it may be possible that DataQuery<D> can be implemented generically for all T: AssociatedData<D> + Node<..>. In this case it would almost be reduced to an implementation detail.
Having the
Node
abstraction it should be possible to design the query methods in a slightly different way:This is nicer as the current interface, as it allows the user to chain this with iterator adaptors instead of using a mutable state captured from the environment.
However, the implementation is certainly somewhat trickier. For instance, it is a bit awkward to generalize over
SomeIterator<_>
without higher-kinded types (which Rust 1.0 will not include). This is also mentioned under limitations in the associated types RFC rust-lang/rfcs#195. A workaround could look like this:Now one would have to implement
QueryableOwned<&'a D>
for&'a T
, so thatT
can implementDataQuery<D>
. This is a bit complicated, so I am not sure whether it is worth the effort.On the other hand it may be possible that
DataQuery<D>
can be implemented generically for allT: AssociatedData<D> + Node<..>
. In this case it would almost be reduced to an implementation detail.