I started converting return types from &'a str to &'a Cow<'input, str> and there is indeed some loss ergonomics as calling code must call .map(AsRef::as_ref) to e.g. compare against Option<&str>.
We could work around this by providing *_cow methods returning Option<&'a Cow<'input, str>> and implement the existing methods as .map(AsRef::as_ref) on top of those so that no implementations need to be duplicated. But that would imply a significant increase in API surface for purely technical reasons.
Another issue that should however be solvable by adding another internal type is that ExpandedName does double duty a) holding references to expanded names from within the document to returned from Node::tag_name which would need to store &'a Cow<'input, str> and b) holding values passed into the API for matching purposes like Node::has_tag_name which need to store &'c str with an unrelated lifetime 'c.
I understand the performance benefits, but the new API is ugly as hell.
I haven't looked into it myself, so I'm not sure if there a better ways, but I would rather leave everything as is.
I started converting return types from
&'a str
to&'a Cow<'input, str>
and there is indeed some loss ergonomics as calling code must call.map(AsRef::as_ref)
to e.g. compare againstOption<&str>
.We could work around this by providing
*_cow
methods returningOption<&'a Cow<'input, str>>
and implement the existing methods as.map(AsRef::as_ref)
on top of those so that no implementations need to be duplicated. But that would imply a significant increase in API surface for purely technical reasons.Another issue that should however be solvable by adding another internal type is that
ExpandedName
does double duty a) holding references to expanded names from within the document to returned fromNode::tag_name
which would need to store&'a Cow<'input, str>
and b) holding values passed into the API for matching purposes likeNode::has_tag_name
which need to store&'c str
with an unrelated lifetime'c
.Closes #88