Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi there, I’ve been noticing the weird-looking trait bounds appearing on the public API, such as
pub fn parse<T: Parser<T> + ParserPos<T>>
.The trait’s type parameters aren’t actually necessary. Perhaps they were used because the author didn’t realize they could achieve the default implementations for
Parse
, which used to rely on a trait bound in the argument,trait Parser<T: ParserPos<T>>
, by using a supertrait bound instead.Anyways, this PR contains multiple commits, starting off with
Parser
,ParserPos
,ParserNeg
pub fn parse<T: Parser + ParserPos>
thenpub fn parse<T: Parse + ParsePos>
thentrait Parse: ParsePos
pub fn parse<T: Parse>
thenParse
andParseNeg
, no longerParsePos
, in public API. The set of types implementingParse
andParsePos
seems to be identical. (Please comment if this observation is wrong under any cfgs, or is intended to become wrong in the future.)pub fn parse_pos<T: ParsePos>
intopub fn parse_pos<T: Parse>
impl_signed
macro, which I felt was more tidy if theimpl
was created by the macro fully, which also stylistically follows common precedent instd
– sorry this is relatively unrelated to the main refactor here, but it’s still something about theParse
[r
] trait I’ve come acrossFeel free to give feedback in case you’re interested in merging only part of these changes.