trait with a len() method but without is_empty() method

[llogiq]

Regarding my failed attempt to fully solve #32 (which would require more typeck than external lints can currently acquire), I thought about the social contract around .len() and .is_empty(). While we don't have a Bounded trait that defines .len() and implements .is_empty(), we can still ask implementers to provide the latter.

There is some precedence to the use of is_empty: E.g. in Java, the Collection interface defines boolean isEmpty() with the usual meaning. C++'s STL defines empty() on all containers, Ocaml at least defines is_empty for stacks. Python's lists and Lua's tables are basically arrays, so they have no problem with using len(_).

In any event, we could add a lint that looks for traits which define .len() but do not define .is_empty() and ask the implementer to consider adding it. This would also remove the need for method lookup on that other lint – if most traits have .is_empty(), we won't need to care for the few remaining false positives, right?

A basic implementation would check_item for ItemTraits and see if the contained TraitItems fail to adhere to the social contract.

[tamird]

I agree with all of this except:

we won't need to care for the few remaining false positives, right?

I don't think false positives are something people should live with and suppress on a case-by-case basis.

[llogiq]

@tamird Thanks for the heads-up. Just to clarify: A false positive in this case would be using an item (trait or type impl) that has a .len(), but no .is_empty() method (and that would have been flagged by this lint). So I think the cost of suppressing the one or two stray false positives is outweighed by the benefit of the lint I have for issue #32 without method lookup.

Please note that this is only an interim solution until rustc_typeck is made accessible to third party lint writers. The process to do this has already begun, so it's only a matter of time until we can do the method lookup and get rid of the remaining false positives.

[Manishearth]

Note that this crate is about lints, and false positives if not too common are okay.

A lot of the things here, like Box<Vec<T>> have legitimate uses too, but very few especially from a newbie perspective.