Jonah Henriksson

> What does `.labels()` do? And what is returned without `.labels()`? > > Is it a performance regression? So I changed the search iterators to return iterators over nodes rather...

Treating the label collector as a special case has fixed the regression for `starts_with`. What's left for this part of the API: - [x] Do the same for prefixes. -...

`longest_prefix` is pretty weird. It does nothing which the name implies. Instead of returning the longest exact match prefix, it returns the first exact match after the label, as long...

Probably just ".shortest()", but that doesn't provide enough information for a top-level API method. Maybe "shortest_suffix"? ("shortest_suffix_or_match" would be more precise, but that's too long IMO) I don't think using...

>Let's figure out what to call our pieces and discuss how we currently handle them. I think your definitions are good. As far as changes/clarifications go: - I think "Query"...

>I didn't want to contend with this point without getting my hands a little dirty, so based off of your work I made [a little branch "label-adverb"](https://github.com/shanecelis/trie-rs/tree/label-adverb) to exercise some...

I'm tempted to merge `set::Trie` and `map::Trie`, since it would simplify implementation so much. For instance, I currently have `set::Trie::inc_search()` return a regular `IncSearch` which returns `NodeRef`s, so to be...

>I don't follow. Do you mean there's nothing you can do with a `trie.starts_with(label)`? What I mean is that there is no iterator chaining possible when `.suffixes()` is implemented for...

Perhaps a better naming convention would be sufficient? Stuff like `starts_with_pairs` doesn't really roll of the tongue TBH (`starts_with` was named before I tried creating the pair and label variants):...

Actually, looking back now, I suppose my concerns about avoiding overhead were misplaced. The search iterators are likely going to do re-allocations anyways, so doing a couple in the beginning...