clang::Type::template_arg_type should return an Option<Type>

[fitzgen]

It isn't clear from the documentation whether or not an invalid type is returned by the FFI call if this type is not a template specialization. We should check whether or not it is, and if it is not return None. We should also bounds check the i parameter.

It will be useful to do this in the method so that every caller doesn't have to remember to do it. One less foot gun!

http://clang.llvm.org/doxygen/group__CINDEX__TYPES.html#ga9645640281c8d088982b2133f58edcb3

I can mentor whoever picks this up.

[highfive]

Please make a comment here if you intend to work on this issue. Thank you!

[jeanphilippeD]

Would it be appropriate to use iterator here instead as suggested for comment children, attributes here #166 ?

[fitzgen]

If we go the iterator route, we can avoid the bounds checks, yes. However, if we do that we should also stop exposing an API to get the nth argument (unless we want to add bounds checks for that API, or use Iterator::nth).

[jeanphilippeD]

Yes, we should remove the template_arg_type and likely the num_template_args API.

There is a small trickiness compared to PR #169 for issue #166.
The number of argument is an optional, but it seem the following interface:
pub fn template_args(&self) -> Option<TypeTemplateArgIterator> (is it idomatic?)

would replace both:
pub fn num_template_args(&self) -> Option<u32>
pub fn template_arg_type(&self, i: u32) -> Type

we use the number, but I don't know if it result in better code than having a single iterator interface.
In PR #169, I feel switching to iterator resulted in simpler calling code.

Regarding getting thenth argument, if it turned out we needed it, we could provide an efficient:
pub fn template_args_from(&self, u32 index) -> Option<TypeTemplateArgIterator>. (is it idomatic?)

[fitzgen]

pub fn template_args(&self) -> Option<TypeTemplateArgIterator> (is it idomatic?)

Either that, or return an empty iterator that doesn't yield any items. I kind of prefer returning an Option since it more straighforwardly conveys that template_args on a non-template specialization doesn't even make sense.

[fitzgen]

switching to iterator resulted in simpler calling code.

Yes, for sure.

Regarding getting thenth argument, if it turned out we needed it, we could provide an efficient:

I think using https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.nth is fine if we already have iterators.