nostr:nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq4cgq353exzmhdsvqjtmw4dq7fvyleuls8umyrvd5umhr4gtx6asqzk33ng yeah, I'm doing parse nodes, and have a `fn matches<'a>(buffer : &Chars<'a>) -> (bool, Chars<'a>);`, and I hope this means that the second return value is in the same `str` referenced by `buffer`.
But I'm totally not sure. And it doesn't work if I pull the <'a> after "matches".
I do know that the placement of the lifetime parameter is imprtsmt. Gotta define a function with lifetimes and be specified before the parameters . its something to do with the complier has to know how lifetimes relate to each other when function sigs are checked.
< 'a > after 'matches' will confuse the complier to associate the lifetime with the parameters.
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq4cgq353exzmhdsvqjtmw4dq7fvyleuls8umyrvd5umhr4gtx6asqzk33ng that may, in fact, be what I need.
But I'm running into another challenge, I'm going to want the furthest into the string that the parse has failed, and I can't do relative comparisons on Chars objects, just .eq(), so I think I need to additionally track how many characters I think I've read. Sigh.
Ehh you shouldn't need to
Why not use an index instead of counting characters? Or return the index of the failure?
Using '&str' could be useful for easier comparisons too
or even if you have some real complex parsing logic , using a state structure could be useful. Could even create a struct to encapsulate the parser state, including the current index and other info
