Yes, and I specifically want the conservative variant - I'd want a
"maybe" for "foo" in that example.
(For context, my test framework determines *while running a test*
whether that test has children, and checks whether to allocate them
when defining them. For me, I only need "yes/maybe" and "no", but
splitting "yes" and "maybe" could be beneficial to others.)
Looking for web consulting? Or a new website?
Send me an email and we can get started.
On Sun, Feb 18, 2018 at 4:19 PM, Mike Samuel <mikesam...@gmail.com> wrote:
> So you want an API that can indicate "might match if there were more input"?
> Is it ok if it is conservative? I.e. it won't incorrectly say "definitely
> wouldn't match given more input" but could tolerate errors the other way?
> For example, /^food(?!)/ would have to say no for "foop" but we might
> tolerate a maybe for "foo".
> On Feb 15, 2018 8:12 AM, "Isiah Meadows" <isiahmead...@gmail.com> wrote:
> I've been working on a test framework, and I'd love to implement
> support for matching tests via regexp-based selectors. It's basically
> impossible without the ability to execute a regular expression and
> test if it matched positively, negatively, or incompletely.
> - If the regexp does not have an end marker, this, of course, can't
> generate a *negative* match, only positive/incomplete ones.
> - If the regexp *does* have an end marker, this is where I actually
> need native support. (This is especially true if group references get
> Any chance this could get added?
> Isiah Meadows
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> es-discuss mailing list
es-discuss mailing list