Starting on 2.0

[Marwes]

Having encountered a few problems when using combine to implement a new parser for embed_lang I think its about time to start thinking how combine-2.0 would look like as the changes I would like to make will break the current API. I still plan to merge the [buffered_stream] and [range_stream] features into 1.0 and 2.0 should not be expected to be widely usable for quite some time even after the features below are implemented.

• Move the associated type Input on Parser to an argument instead. As Input is an input type on the trait this will let parsers be a bit more flexible with not much downside. Inference often fails with this change.
• Make Stream types store the position internally instead of relying to the State wrapper. This should let streams be a bit more flexible when it comes to position handling.
• Possibly changing the exported API. Personally I feel that the root module reexports a bit to much currently while still missing a few functions/types. The combinator module has also become rather large and should possibly be split.

If anyone has any other changes or ideas which would break the current API please comment and discuss them in this issue.

[sbstp]

It would be nice if you could parse bytes using this library. It probably can already, but a lot of the primitives have a where Stream<Item=char>> which makes it impossible to use them with bytes. Maybe there could be a str and a bytes module where the non-generic primitives are located.

[Marwes]

@sbstp It is possible to create parsers for other things than chars easily using satisfy and token both of which work with any kind of streams. It might be nice to have some specialized variants for bytes as well though, what kind of functions would you expect from a byte module?

[sbstp]

I would need crlf, digit, letter, space, spaces, strings->bytes. Most of these are an exact copy of the char literal form with a b (to make it a byte instead of char) before it. Could probably be generated using a macro.

[Marwes]

So mostly primitives to work with ascii strings then? I suppose that would be a nice addition (which could be added to 1.x as well). It is probably a bit excessive to pull in a libc dependency just for the is_alpha etc functions so I think either reimplementing those functions or pull in https://crates.io/crates/ascii

[Marwes]

Closed by 2.0.0