Type coercion for `Input` in `8.0.0`

[IpFruion]

Problem

When upgrading from 7.* to 8.0.0 I noticed that tag(b"hello") now produces an error.

the trait `Input` is not implemented for `&[u8; 5]`

This is due to the shift from the InputLength trait being implemented for tag in 7.* https://docs.rs/nom/7.1.3/nom/bytes/complete/fn.tag.html

To tag must implement Input in 8.0.0: https://docs.rs/nom/8.0.0/nom/bytes/complete/fn.tag.html

Interim Solution

A way to fix this in the interim is to coerce the type into &[u8] which Input is implemented for. i.e. tag(b"hello" as &[u8]).

Possible Fix

Implement Input for &[u8; N] for any const N: usize

[Hywan]

I met the same problem today. This isn't possible to implement to impl<'a, const N: usize> Input for &'a [u8; N] because of Input::take (and other sibling methods) which returns Self (or (Self, Self) in the case of take_split):

nom/src/traits.rs

Lines 42 to 47 in 2cec1b3

	/// Returns a slice of `index` bytes. panics if index > length
	fn take(&self, index: usize) -> Self;
	/// Returns a slice starting at `index` bytes. panics if index > length
	fn take_from(&self, index: usize) -> Self;
	/// Split the stream at the `index` byte offset. panics if index > length
	fn take_split(&self, index: usize) -> (Self, Self);

We may want to refactor that by splitting the Input trait into 2 traits. Thoughts @Geal? I didn't check the implication of that yet. It's probably more trait bound checks for a couple of combinators.

[Hywan]

Alternatively, we can add another associated type for the output of take() & siblings, à laIter & IterIndices:

nom/src/traits.rs

Lines 23 to 36 in 2cec1b3

	/// Parser input types must implement this trait
	pub trait Input: Clone + Sized {
	/// The current input type is a sequence of that `Item` type.
	///
	/// Example: `u8` for `&[u8]` or `char` for `&str`
	type Item;
	/// An iterator over the input type, producing the item
	type Iter: Iterator<Item = Self::Item>;
	/// An iterator over the input type, producing the item and its byte position
	/// If we're iterating over `&str`, the position
	/// corresponds to the byte index of the character
	type IterIndices: Iterator<Item = (usize, Self::Item)>;

Something like:

pub trait Input: Clone + Sized {
    // …

    type TakeOutput;

    fn take(&self, index: usize) -> Self::TakeOutput;

    // …
}

[Geal]

that might make it way more complex. Are there other alternatives? maybe making Parser::parse take a Into<I> ?

[IpFruion]

@Hywan Yeah that makes sense why that won't do it.

@Geal Another option to the list other than splitting up the Input trait could be a separate one that can do the conversion i.e.

pub trait IntoInput {
    type Input: Input;
    fn into_input(self) -> Self::Input;
}

impl<'a, const N: usize> IntoInput for &'a [u8; N] {
    type Input = &'a [u8];
    fn into_input(self) -> Self::Input {
        self as &[u8]
    }
}

impl<T: Input> IntoInput for T {
    type Input = T;
    fn into_input(self) -> Self::Input {
        self
    }
}

fn tag<I>(input: I) where I: IntoInput {
   let input = input.into_input();
}

Or something of the like. Similar to the Into<I> but with the trait bounds.

[marcdejonge]

I like this IntoInput solution. This could applied in more places, where we transparently translate any parameter that supports it into the correctly supported Input type. You can also provide a good standard implementation such that no API breaks, but you do accept way more types as inputs.

[marcdejonge]

Something like this?

https://github.com/rust-bakery/nom/pull/1810/files#diff-172747fc43e38d33de743b2d5f564ad6440570670af7aa912235399448a55c7cR570