[issues-1223] Add take_from combinator

[ikrivosheev]

Close: #1223

[Xiretza]

I think this might be better implemented as a combinator void(p) with the semantics of value((), p) (which would be used like void(take(n))), rather than a specialized combinator for skipping a fixed number of elements.

[ikrivosheev]

I think this might be better implemented as a combinator void(p) with the semantics of value((), p) (which would be used like void(take(n))), rather than a specialized combinator for skipping a fixed number of elements.

take(n) - also create new slice. The idea was not to create unnecessary slice and immediately skip a piece

[Xiretza]

Apart from inlining probably removing it outright, "creating a slice" is an incredibly cheap operation - it's really just a single addition. I don't think there's much to optimize here; if you have benchmarks suggesting otherwise, those would of course be valuable to see.

[ikrivosheev]

Not everyone works only with slices, some one can work with Read + Write or something else. And it looks very strange that in order to skip a piece of data, you need to call take. It's logical to have some way to skip (real skip, not take then skip) piece of data.

[epage]

Not everyone works only with slices, some one can work with Read + Write or something else. And it looks very strange that in order to skip a piece of data, you need to call take. It's logical to have some way to skip (real skip, not take then skip) piece of data.

To clarify, are you working with Read + Write and needing ti for that?

I'm also concerned that this would need a proliferation of different combinators to fully flesh out the idea of "needing" skip support (e.g. skip_while, skip_until) which would bloat nom. I feel like more concrete justification would be needed to justify that.

[ikrivosheev]

@Geal hello! I have rebased PR, can you review?