Convert ZeroCopy to ouroboros. #208
Conversation
|
Yes, this looks very promising indeed! Also cc @joshua-maros just because they may be interested in an application of their crate :) |
|
Thanks for the mention, I always appreciate seeing something I made help someone out! As a side note, I've recently published |
Use a helper function in `parse_many_into` to support parsing into any container that implements Extend. Refactor Capabilities to use it. Delete ZeroCopy and associated bits. Move Flag into it's own module in types.
|
Pushed an update the switches |
| assert_eq!( | ||
| names[0].attributes(), | ||
| first.attributes(), |
There was a problem hiding this comment.
I think it'd be hugely valuable to continue to support indexing here if at all possible. I suspect all that'd be needed is to implement Index for Names and Fetches.
There was a problem hiding this comment.
I struggled to implement Index or Deref for this. The issue is the lifetime param on the Output associated type, since type Output = Name<'a>. The compiler wants the same lifetime on Output, but generic associated types are unstable.
We could probably get around this by replacing Names and Fetches with a generic container that takes a type param (we could call it.. ZeroCopy?), and then implement Deref or Index the same way that it is done for ZeroCopy, since the lifetime would be encapsulated in the generic type. Then Names is just ZeroCopy<Name<'_>>. When I try this I end up struggling against the constructor function signatures that ouroboros wants in the TryBuilder structure to initialize the self ref structure.
So instead I implemented a get() function, which trivially maps the underlying vector get() function and lets you just get an indexed member from the container. I personally kind of prefer this anyway, since Index can panic, but I get that the Index trait gives nice [] syntax.
If we want to impl Index or Deref (I think Deref would be better?), I am not sure how to make this work in the ouroboros context. I imagine that if it is doable then it is probably kind of simple, but I couldn't get it going.
There was a problem hiding this comment.
Oof, yeah, that's awkward. You can impl<'a> Index<usize> for &'a Fetches (playground), but it means &fetches[0] won't work, only (&fetches)[0], which is both hard to discover and ugly. I'm okay with fn get 👍
|
All of those comments look entirely reasonable! I'll be able to get it done soonish, and it should be gtg for when you get back from vacation. |
| assert_eq!( | ||
| names[0].attributes(), | ||
| first.attributes(), |
There was a problem hiding this comment.
Oof, yeah, that's awkward. You can impl<'a> Index<usize> for &'a Fetches (playground), but it means &fetches[0] won't work, only (&fetches)[0], which is both hard to discover and ugly. I'm okay with fn get 👍
Nope! Let me fix the title there... :) |
mordak
changed the title
|
Looks like the tarpaulin failure is due to xd009642/tarpaulin#756 btw. |
This converts
Capabilitiesto use ouroboros instead of the localZeroCopy.Because of all the magic that ouroboros
self_referencingmacro adds (CapabiltiesTryBuilderand friends) I found it was simpler to move the parsing bit into theCapabilitiesstruct itself. I actually prefer this, since it keeps everything related toCapabilitiesin one place, but I understand if you prefer to keep everything related to parsing inparse.rs.Anyway, if this approach for moving from
ZeroCopyto ouroboros looks like a good approach, then I can do the rest of it similarly here, andZeroCopycan go away, and we can close #125 .Thoughts?
This change is