Support other input types than &[u8]

[csarn]

I'm interested in using nom-derive with inputs that are not &[u8], i.e. with https://github.com/fflorent/nom_locate.

Would it be possible to make the derived impls generic?

Also, how hard would it be? I might try to implement it myself, but would need some pointers where to start.
It seems there is already an InputSlice trait, could it suffice to change the generated code to be generic over that trait?

[chifflier]

The idea is interesting.
I had a look at the problem, but this seems quite complex in practice: to be able to use some nom combinators automatically, the input type must implement some traits. For example, to use take, the input must implement Slice<RangeFrom<usize>> + InputIter<Item = u8> + InputLength (see take documentation).
However, this list differs for each combinator and is not easy to derive automatically.

There may be some solutions:

• let crate user add manually the where clause: not really intuitive nor easy to use
• try to infer the where clause: requires to maintain a map of known combinators / required traits, and accumulate/add them when parsing, and add them at end. This can be quite complex

Currently the derived code only implements &[u8] because of the above difficulties, and InputSlice is not used in derived code. This is not really intentional, and could be changed.

Overall, the problem always comes to this: being able to guess the constraints and the parameters/generics, and be able to generate some code that is 1) acceptable by the compiler 2) working. For example, making the error type generic brought huge difficulties: sometimes the constraints must be on the generated impl, sometimes on the fn (other Rust complains the generic parameter is not constrained by type), etc. This is planned for release 0.9.0.

That said, it is not impossible to do (and I just succeeded for generic errors, so this may be a first step). I will have a look when possible, and if you have any suggestion or good idea it is welcome!