Open mikebaldry opened 7 years ago
Hi @mikebaldry,
Sure, I see your point. Take into account that nil
only means that the input didn't match, and I'm not sure that something like that must be considered an error per se in any use case scenario.
Perhaps in some use cases that really is an error, but not in others. And that is something really related to how and where you are using it.
But, semantics aside, I'm open to pull requests to improve the little beast :)
Best regards!
Another point of view: apply
will return the rule that matches, while nil
means: "Hey I didn't match any rules for that input, so I'm giving you nothing, zero, zip, nil. And that's cool too."
I understand that point of view and it makes sense. It would be nice to know where it fell over though, mainly for debugging purposes :) I'll have a think
Hi there,
When trying to match against invalid data,
apply
just seems to returnnil
, is there some way to generate a nicer result, perhaps where it was unable to match the next byte, at what position and what it expected and what it got?It would be good if
apply
returned a standard{:ok, capture_result}
or{:error, something_else}
Cheers.
Great library by the way :)