but the compiler complains about an ambiguous use of 'buildExpression' on the first Optionally statement. If I add a string literal parser inside of the first Optionally block or inside of the top-level Parse block the error goes away.
I get a bit lost when there are lots of generics and lots of type inference is happening but it seems to me like Swift is just having a hard time inferring the type of Input so it doesn't know which overload of buildExpression to use.
The parsers that I'm building are usually pulling values out of the middle of a string, and the string may not contain the value at all, which could also be part of the problem since what's talked about in the early videos of the Parsing collection of episodes is just parsing the start of a Substring so I'm wondering how much that influenced the final API design for this library.
As an example of the parsers I'm building, here's one I wrote to parse video resolution from a string:
I'm wondering if it's possible to build a parser of only optional values using the
Optionally
parser. I've tried the following:but the compiler complains about an
ambiguous use of 'buildExpression'
on the firstOptionally
statement. If I add a string literal parser inside of the firstOptionally
block or inside of the top-levelParse
block the error goes away.I get a bit lost when there are lots of generics and lots of type inference is happening but it seems to me like Swift is just having a hard time inferring the type of
Input
so it doesn't know which overload ofbuildExpression
to use.The parsers that I'm building are usually pulling values out of the middle of a string, and the string may not contain the value at all, which could also be part of the problem since what's talked about in the early videos of the Parsing collection of episodes is just parsing the start of a
Substring
so I'm wondering how much that influenced the final API design for this library.As an example of the parsers I'm building, here's one I wrote to parse video resolution from a string: