Replies: 3 comments 1 reply
-
@heyltsjay I think this is working as intended. All parser optionality is handled explicitly via It might be possible that another overload could be introduced, but we're not sure result builder type inference and/or type ambiguity would interfere. For example, if it weren't for your let p = Field("email") // Parser<Substring, ???> Some magic use of |
Beta Was this translation helpful? Give feedback.
-
I'm also going to move this to a discussion since it's more about discussing a potential feature than a bug in the library. |
Beta Was this translation helpful? Give feedback.
-
This all sounds fair enough, albeit breaking my mental model somewhat of how other optional query params are treated. |
Beta Was this translation helpful? Give feedback.
-
In the following example I would expect some way to coalesce
Field("password")
to nil withoutOptionally
, but it seems like there is no way to distinguishnil
as being the default value itself, rather than the absence of one. I was surprised the compiler was happy with the pattern but that the tests were failing to parseapp://[email protected]
Beta Was this translation helpful? Give feedback.
All reactions